© Алексей Лобанов
- эксперт Департамента системных решений IBS
Статья была опубликована в журнале Сетевой
журнал
№4/2003
Для того чтобы ERP-система предприятия была способна выполнять стоящие перед ней бизнес-задачи, предоставляемые ею сервисы должны обладать требуемой функциональностью, производительностью и доступностью. Функциональность достигается за счет тщательного проектирования системы. Для обеспечения заданной производительности необходимо правильно определить параметры используемых технических средств; с этой целью специалисты, устанавливающие новую ERP-систему, либо проводят технический аудит той системы, которая уже имеется, замеряют ее производительность, моделируют будущие нагрузки, либо (например, когда система создается с нуля) рассчитывают значения параметров по специальным методикам, разработанным производителями оборудования и ПО. Чтобы гарантировать высокую доступность (availability) сервисов ERP-системы, важно в первую очередь грамотно проработать архитектуру системы и разработать комплекс специальных мер.
Одновременно предприятие также стремится по возможности сократить совокупную стоимость владения системой (Total cost of ownership – TCO). Главными путями для этого являются, во-первых, внедрение системы эксплуатации, позволяющей удешевить администрирование ERP-системы и спланировать расходы на ее его модернизацию, а во-вторых, консолидация технических средств и обслуживающего персонала в центре обработки данных (ЦОД). Такой центр представляет собой комплексное организационно-техническое решение для создания высокопроизводительной и отказоустойчивой информационной инфраструктуры. Можно сравнить центры обработки данных со старыми вычислительными центрами (ВЦ), которым также была присуща идея консолидации ресурсов и организации эксплуатационного процесса для поддержания соответствующего уровня качества услуг. Однако сейчас эта идея возрождается на новом качественном и архитектурно-техническом уровне: если старые ВЦ были ориентированы на предоставление услуг по организации вычислений, то современные ЦОД предоставляют услуги прежде всего в виде информационных сервисов. Таков вкратце перечень задач, которые встают перед предприятием, внедряющим ERP-систему. В этой статье мы рассмотрим меры по обеспечению высокой доступности сервисов ERP.
Информационные сервисы ERP-системы делятся на критичные для выполнения основных бизнес-функций и вспомогательные. Критичными считаются такие сервисы, недоступность которых в течение длительного времени способна повлечь серьезные потери, причем не только финансовые. Так, задержка в обслуживании клиентов может привести к ухудшению имиджа компании, из-за чего, в свою очередь, будут потеряны потенциальные или даже текущие клиенты.
Приемлемое время недоступности информационных сервисов зависит от требований бизнеса и для каждого предприятия определяется индивидуально. Оно варьируется от нескольких минут до нескольких часов, и обычно эта цифра фиксируется в соглашении об уровне сервиса (Service Level Agreement – SLA).
Все методы, применяемые для обеспечения высокого уровня доступности ERP-систем, взаимосвязаны, но условно их часто делят на две группы: архитектурные и организационные. Архитектурные методы можно охарактеризовать одним словом – дублирование. Дублирование сокращает время восстановления работы ERP-системы после сбоя. Оно может осуществляться на всех уровнях ИТ-инфраструктуры: установка резервных компонентов в серверы, выполняющие критичные функции, создание кластера таких серверов, резервное копирование информации и создание резервного центра для ЦОД ERP-системы. Организационные методы предназначены для построения такого процесса эксплуатации, который свел бы до минимума время обнаружения и устранения неисправностей в ERP-системе. К ним относятся мониторинг, план восстановления после аварий и тренинг персонала. Рассмотрим указанные методы подробнее.
Кластером называется группа соединенных между собой серверов, которые функционируют как единое целое и работа которых координируется для решения поставленной задачи. Результатом создания кластера может стать, например, обеспечение высокой доступности информационного сервиса (так называемые кластеры высокой доступности, или HA-кластеры – от англ. high availability) или распараллеливание процесса решения сложной вычислительной задачи. Современное кластерное ПО позволяет избежать длительного простоя системы в случае cбоя или выхода из строя оборудования, ошибки в программе или ошибочного действия обслуживающего персонала при условии, что не произошло разрушения данных. Восстановить разрушенные данные кластер не может, что делает необходимым создание высоконадежной системы хранения данных, включающей подсистему резервного копирования.
Рис.1. Схема кластера.
Кластер состоит из аппаратной и программной частей. Аппаратная часть помимо узлов кластера, т. е. самих объединенных серверов, включает среду их взаимодействия – heartbeat, реализуемую с помощью либо обычного Ethernet, либо специальных высокоскоростных сред передачи данных с низкой латентностью, таких, как SCI, HP HyperPlex, Sun WildCat. Для того чтобы все узлы кластера могли обеспечить работу одного информационного сервиса, они должны иметь доступ к общему дисковому пространству. Оно реализуется созданием общих для узлов кластера томов на одном отказоустойчивом дисковом массиве (или двух зазеркалированных дисковых массивах), подключенном ко всем узлам кластера. Для кластера, состоящего из многих узлов, наилучшей инфраструктурой доступа серверов к общему дисковому массиву является сеть хранения данных (SAN), поскольку протокол SCSI не обеспечивает устойчивой работы шины более чем c двумя инициаторами.
Рис.2. Архитектура системы резервного копирования.
Высокая доступность информационных сервисов, предоставляемых узлами кластера, обеспечивается кластерным ПО. Это ПО с помощью специальных сервисов или скриптов отслеживает работоспособность информационных сервисов, выполняемых узлами кластера. В случае сбоя, вызванного отказом диска, сетевого интерфейса или самого приложения, кластерное ПО переносит соответствующий сервис на другой узел. Под переносом здесь понимается: остановка приложения (если оно еще работало) на первом узле, размонтирование общих дисковых томов, монтирование их на втором узле, перенос IP-адреса (алиаса) с первого на второй узел, запуск приложения. Если в кластере больше двух узлов, то информационные сервисы вышедшего из строя узла переносятся на другие узлы в зависимости от правил, либо заданных администратором, либо определенных самим кластерным ПО на основе данных о загрузке работоспособных узлов.
Указанный механизм работы используется в кластерах высокой доступности. Ряд производителей ПО для таких кластеров встраивают в свои продукты функции распределения нагрузки между узлами, выполняющими одно и то же приложение и работающими при этом с общей копией данных. Однако реализация этой возможности существенно зависит от приложения. В настоящее время кластерное ПО способно обеспечивать работу с общей файловой системой и с общей базой данных СУБД Oracle (Oracle Parallel Server, Real Application Cluster).
При решении вопроса о создании кластера необходимо оценить три основных критерия: возможный ущерб для предприятия от простоя критичных информационных сервисов, среднее время восстановления работоспособности этих сервисов без применения кластера и стоимость реализации кластера. Следует также учесть, что доступность как критичных, так и вспомогательных информационных сервисов зависит от производительности системы. При низкой производительности время отклика сервиса может превысить допустимый предел, что также следует рассматривать как недоступность сервиса.
Система резервного копирования представляет собой служебную подсистему системы хранения данных (СХД) и является обязательным компонентом решения по обеспечению высокой доступности ERP-системы. Она позволяет восстановить работоспособность информационных сервисов даже в тех случаях, когда повреждены данные.
Создание централизованной системы резервного копирования дает возможность сократить (по сравнению с децентрализованной) совокупную стоимость владения ИТ-инфраструктурой за счет оптимального использования аппаратуры и сокращения расходов на администрирование. Такая система имеет многоуровневую архитектуру (см. рис. 2), включающую:
Администратор системы ведет список клиентов резервного копирования, устройств записи и носителей данных, а также составляет расписание резервного копирования. Вся эта информация содержится в специальной базе, которая хранится на сервере управления резервным копированием.
В соответствии с расписанием или по команде оператора сервер управления дает программному агенту, установленному на компьютере-клиенте, инструкцию приступить к копированию данных согласно выбранной политике. Агент начинает сбор данных, подлежащих резервированию, и их передачу на указанный сервером управления сервер копирования, который, в свою очередь, сохраняет полученные данные на подключенное к нему устройство резервного хранения данных. Информация о процессе (какие файлы копировались, на какие носители и т.п.) сохраняется в базе сервера управления, чтобы можно было быстро найти данные, если возникнет необходимость их восстановления на компьютере-клиенте.
Чтобы сохраненные данные были непротиворечивыми, они не должны подвергаться изменению в процессе сбора и копирования. Поэтому перед началом этой процедуры приложения компьютера-клиента должны завершить все транзакции, сохранить содержимое кэш-памяти на диске и приостановить работу. Соответствующие действия инициируются по команде программы-агента.
Так как система резервного копирования относится к числу служебных, т.е. нагрузка на вычислительные средства, которую она создает, не является полезной с точки зрения предоставления информационных сервисов, эту нагрузку желательно уменьшить. Данная задача распадается на две: сокращение так называемого "окна резервного копирования" (т.е. времени, в течение которого компьютер-клиент выполняет резервное копирование) и уменьшение трафика соответствующих данных в корпоративной ЛВС. Внедрение системы резервного копирования в составе СХД позволяет сократить ”окно” благодаря интеграции со средствами создания PIT-копий, реализованными в современных дисковых массивах: с данных практически мгновенно делается ”моментальный снимок”, и резервное копирование выполняется уже с этого снимка, а сервер продолжает работу. Снизить нагрузку на локальную сеть помогут технологии LAN-free backup и Serverless backup, предоставляемые SAN-сетями.
Если предприятие располагает резервным центром (РЦ) обработки данных или планирует его построить, то для системы резервного копирования необходимо предусмотреть интеграцию с этим центром. Переход к использованию РЦ влечет за собой изменения политики защиты и хранения данных, условий эксплуатации и зачастую сопровождается модернизацией существующей системы резервного копирования. В частности, вычислительные средства РЦ позволят выполнять обязательное тестирование резервных копий данных на работоспособность, разгрузив вычислительные средства основного ЦОД и упростив данную процедуру. Также возможно организовать хранение дубликатов резервных копий в РЦ, а не в стороннем удаленном хранилище.
Резервный центр позволяет восстановить работоспособность информационных сервисов при выходе из строя всего серверного комплекса по причине техногенной или природной катастрофы. С архитектурно-технической точки зрения это ЦОД, хотя и не копия основного, поскольку он должен быть рассчитан на дублирование не всех сервисов, а только тех из них, без которых продолжение работы предприятия невозможно.
В РЦ необходимо иметь актуальные копии данных, требуемых для работы информационных сервисов ERP-системы, а также их резервные копии. Кроме того, следует проработать меры, которые обеспечат своевременный перевод выполнения критичных сервисов на вычислительные средства РЦ в случае выхода из строя основного ЦОД.
Рис.3. Пример архитектуры ERP-системы на базе SAP R/3.
Для получения актуальных копий данных применяются технологии репликации; самой передовой из них на сегодня является так называемая аппаратная репликация (в действительности она выполняется встроенным ПО интеллектуальных дисковых массивов, но это происходит абсолютно "прозрачно" для подключенных к массивам серверов). Чаще всего аппаратная репликация между массивами организуется по протоколу Fibre Channel (FC), основному для SAN-сетей. Одним из достоинств SAN является возможность быстрой передачи данных на большие расстояния не только средствами репликации, но и другими методами, например зеркалированием. Сеть хранения данных, соединяющая ЦОД и РЦ, позволяет объединить все устройства хранения в единый пул, одновременно доступный из обоих центров всем серверам, подключенным к SAN.
Перевод критичных информационных сервисов на вычислительные средства РЦ может осуществляться как автоматически, так и по команде оператора. Автоматический перевод используется в тех случаях, когда очень высоки требования к срокам восстановления доступности (не больше нескольких минут) или в РЦ отсутствует квалифицированный персонал. Для организации автоматического запуска информационных сервисов используются кластерные технологии, объединяющие серверы ЦОД и РЦ в единый серверный комплекс с удаленными друг от друга узлами.
С помощью технологии SAN можно организовать резервное копирование информационных массивов из ЦОД на устройства резервного хранения данных, расположенные в РЦ. Это позволит регулярно тестировать резервные копии данных (что необходимо для проверки работоспособности информационных сервисов после восстановления данных с этих копий), не создавая помех для работы информационных сервисов в ЦОД.
Если расстояние между ЦОД и РЦ превышает 10 км или предприятие не располагает достаточным количеством "темной" оптики, для связи между двумя центрами применяется технология уплотненного спектрального мультиплексирования (DWDM – Dense Wavelength Division Multiplexing), которая позволяет оптимальным образом использовать оптоволоконные ресурсы и передавать трафик Fibre Channel, ESCON, а также Ethernet.
Организации процесса эксплуатации посвящено большое количество статей и книг; кроме того, существует "библиотека знаний" о том, как его правильно строить, – ITIL. Поэтому здесь приводится лишь краткое перечисление основных организационных методов. Но необходимо отметить, что применение организационных методов является обязательным, даже более важным, чем применение перечисленных выше архитектурных.
Рассмотренные выше методы обеспечения высокой доступности инвариантны к типу информационной системы и применимы для всех ERP-систем. Целесообразность применения того или иного метода зависит от критичности конкретной системы для бизнеса предприятия и объема финансовых потерь в случае ее простоя. Однако при выборе конкретных мер необходимо учесть архитектурные особенности данного ERP-решения. Для того чтобы сократить время возможного простоя, в системе необходимо выявить единые точки отказа (Single Point Of Failure – SPOF) и постараться их ликвидировать путем применения перечисленных выше методов.
Рассмотрим ERP-систему на базе продукта SAP R/3. Одним из вариантов внедряемых архитектур SAP R/3 является классическая схема из трех серверов – "продуктивного", "тестового" и "сервера разработки" (см. рис. 3). Очевидно, что критичным для работы ERP-системы является "продуктивный" сервер. Снизить время его возможного простоя можно, продублировав все те его компоненты, которые являются SPOF. Но это не всегда осуществимо и зависит от модели используемого сервера. Другой вариант – продублировать работу "продуктивного" сервера на одном из двух оставшихся– "тестовом" или "разработки". Для этого как минимум необходимо, чтобы "продуктивный" и дублирующий серверы имели доступ к одним и тем же данным, например, были подключены через SAN к общему дисковому массиву. Если у предприятия недостаточно квалифицированных кадров, чтобы организовать круглосуточное дежурство администраторов, которые смогут в случае неисправности "продуктивного" сервера перевести работу модулей SAP R/3 на дублирующий, рекомендуется создать кластер высокой доступности, способный делать это автоматически.
Ряд модулей SAP, особенно продукты серии mySAP, рекомендуется развертывать на серверном комплексе с трехуровневой архитектурой: клиент, сервер приложений, сервер баз данных (предыдущий рассмотренный вариант имел двухуровневую архитектуру – клиент и сервер). Трехуровневая архитектура характерна и для ERP-систем, построенных на основе продуктов Oracle Applications. В этой архитектуре сервер приложений является менее критичным элементом, чем сервер баз данных, отвечающий за работу с самым ценным элементом системы – данными. Если сбой сервера может быть ликвидирован путем перезагрузки (это довольно частый случай), то сервер приложений перезагрузится и продолжит работу намного быстрее, чем сервер баз данных, которому необходимо будет запускать СУБД и в случае аварийной остановки СУБД выполнять восстановление баз. Серверов приложений может быть несколько, и они могут дублировать работу друг друга без использования кластерных технологий. Организовать дублирование сервера приложений проще, чем сервера баз данных, поскольку серверы приложений не хранят информацию, а обращаются за ней к серверам баз данных. Таким образом, в системе с трехуровневой архитектурой основное внимание необходимо обратить на серверы баз данных и именно для них применить такие методы повышения доступности, как дублирование компонентов и кластеризация.
Еще одной особенностью реализации ERP-систем на основе продуктов SAP является то, что для ряда модулей SAP, например BW и HR, рекомендуется использовать выделенные серверы. Архитектура системы в таком случае будет двухуровневой и содержащей несколько серверов. Если для обеспечения высокой доступности такой ERP-системы использовать кластерную технологию, то оптимальным будет кластер с топологией N+1, где один сервер резервирует работу остальных и в случае выхода из стоя одного из них берет на себя выполнение его функций. Когда в качестве платформы ERP-системы применяется один из промышленных вариантов UNIX, проблем нет: все основные производители (Sun, HP и IBM) предлагают кластерные решения, поддерживающие топологию N+1 для большого числа (как минимум до восьми) узлов. Однако для платформы MS Windows NT/2000 кластер с четырьмя узлами поддерживается только в варианте ОС DataCenter и для фиксированного числа аппаратных конфигураций. Альтернативой в данном случае может служить кластер VERITAS Cluster Server 2.0 for Windows, который поддерживает конфигурации до 32 узлов.
В своих проектах компания IBS применяет системный подход, учитывающий особенности построения ERP-систем, о которых здесь рассказывалось, и позволяющий благодаря этому получать наиболее эффективные решения для предприятия любой отрасли. Регулярный технический аудит ЦОД позволяет предприятиям поддерживать соответствие ERP-систем заданным характеристикам и своевременно принимать меры по их модернизации. Данный процесс может быть упрощен, если в ЦОД развернута полнофункциональная система эксплуатации.
Рис.4. Кластер с топологией N+1 для ERP-системы на базе SAP R/3
Полный цикл работ, выполняемых компанией IBS по созданию или модернизации ЦОД ERP-системы, обеспечивает максимальное соответствие бизнес-требованиям заказчика и включает в себя следующие услуги:
Дополнительная информация
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||
