Здесь публикуется третья статья Сергея Котова из цикла статей по обеспечению надежности работы Axapta на этапе эксплуатации. Цель - представить системный и практичный подход к организации высоконадежного режима работы Microsoft Axapta для этапа промышленной эксплуатации системы.

Сергей Котов, serge_kotov@mail.ru

AxaptaReliablity.doc (482Kb, Для загрузки требуется регистрация на форуме у Mazzy)

Обеспечение надежности работы Microsoft Axapta

Цель статьи – представить системный и практичный подход к организации высоконадежного режима работы Microsoft Axapta для этапа промышленной эксплуатации системы.

 

Начало…
Предыдущая часть …

4. Технические решения для Microsoft Axapta

Прямое влияние технической архитектуры системы на состояние надежности, особенно на критерии доступности и производительности очевидно.

Ниже представлены некоторые опробованные на практике и хорошо себя зарекомендовавшие технические решения и советы по обеспечению надежности системы Axapta. Безусловно, могут быть и другие подходы к проектированию архитектуры, да и технический прогресс не стоит на месте.

 

4.1. Выбор оптимальной технической архитектуры

Выбор оптимальной архитектуры для системы Axapta обусловлен компромиссом между следующими факторами:

Очень важно не ограничится текущими потребностями, и постараться учесть перспективы развития системы Axapta, заложив основы архитектуры, легко масштабируемые по мере роста потребности. В первую очередь это касается систем хранения данных. Здесь можно смело использовать современные технологии. В дисковых массивах, построенных по технологиям SAN (storage area network), например IBM FAStT 600, можно увеличить объем логических дисков на лету, без выключения сервера и дисковой стойки.

Ниже представлены два возможных варианта архитектуры системы Axapta.

Варианты архитектуры системы Microsoft Axapta

Это типичный базовый вариант для случая нежестких требований к надежности, базы данных объемом до 100 GB и количества одновременно работающих физических пользователей до 70 человек.

Рабочая база данных размещена на сервере SQL 1, подключенным к одной или нескольким внешним стойкам RAID – массивов. Доступ пользователей осуществляется через внешний сервер приложений AOS 1. Архивное копирование рабочей базы данных производится на второй сервер SQL 2. Там же содержатся и вспомогательные базы данных для целей разработки и тестирования. Перенос архивированных и сжатых архиватором данных на внешний носитель (лента или DVD-R) в данном случае может осуществляться через внешний ПК. Серверы AOS 1 и SQL 1, AOS 2 и SQL 2, SQL 1 и SQL 2 соединены друг с другом напрямую сетевыми соединениями c привязкой IP адресов минуя коммутатор ЛВС.

В случае сбоя, рабочая база может быть восстановлена для пользователей на связке серверов AOS 2 и SQL 2. Время восстановления зависит от скорости разворачивания архивной копии и восстановления по журналам транзакций, т.е. может составить несколько часов.

Более продвинутый вариант, удовлетворяющий более строгим требованиям к надежности и соответствующий более крупному решению (база данных до 300+ GB , количество активных пользователей до 200+):

вариант архитектуры

В данном случае доступ пользователей к рабочей базе данных осуществляется через кластер серверов приложений AOS 1 – AOS 3. Серверы баз данных, основной SQL 1 и второй SQL 2 подключены к стойкам RAID массивов RAID 1 и RAID 2 по интерфейсам Fibre Channel (FC). На RAID 1 располагается рабочая база данных, на RAID 2 – архивная и все вспомогательные, а также версия standby рабочей базы данных. Перекрестное соединение RAID массивов и серверов по интерфейсу FC позволяет, при необходимости, подключить любую базу данных к одному из серверов SQL в течение нескольких минут.

Архивные копии базы данных периодически переносятся на одинарный накопитель Ultrium tape drive или ленточную библиотеку.

Во всех случаях рекомендуется использовать рэковую (rack) архитектуру, встроенную в соответствующие стойки с вмонтированными источниками бесперебойного питания.

 

4.2. Сервер баз данных

Для технической архитектуры системы Axapta сервер рабочей базы данных является наиболее важным звеном, т.к. устойчивость работы всей системы в первую очередь зависит от состояния ее базы данных.

В случае жесткого ограничения выделения финансовых средств, наибольший приоритет нужно присвоить к удовлетворению требований к надежности (производительности) именно сервера баз данных, пусть даже в противовес другим компонентам системы.

В режиме эксплуатации на предприятии объем базы данных Axapta , скорее всего, будет измеряться гигабайтами или десятками гигабайт. По этой причине, а также с точки зрения обеспечения приемлемой производительности и масштабируемости сервер баз данных лучше организовать по модульной архитектуре – собственно сервер и отдельные стойки RAID массивов, одна или несколько штук, соединенные по интерфейсу SCSI или FC.

Достаточно сложно дать конкретные рекомендации по выбору технических характеристик, т.к. вариация интенсивности операций может быть значительной даже для внешне схожих условий. Тем не менее, для первоначальной оценки в первом приближении можно ориентироваться на нижеследующие графики.

Для собственно сервера баз данных наиболее критически важные параметры – тип и количество процессоров, а также объем оперативной памяти.

Рекомендуемое число процессоров в зависимости от числа пользователей

ASU – Axapta Standard User, некий стандартный пользователь, создающий нагрузку на систему, эквивалентную нагрузке по вводу и обработке пятидесяти строк заказов в час. Подробно об определении ASU можно найти в документе Axapta Sizing Guidelines.

Зависимость размера памяти от объема БД

Очень важна зависимость производительности сервера баз данных Axapta от соотношения объема оперативной памяти и размера базы данных. В случае если объем оперативной памяти, выделенной под нужды процесса SQL Server, составляет менее ~10 % от размера файлов данных, то, скорее всего, следует ожидать интенсивных операций ввода – вывода с дисковой подсистемой и, соответственно, в эти моменты будет заметно снижаться нагрузка на процессоры сервера.

Так как для 32-разрядных операционных систем Windows ограничение объема напрямую адресуемой оперативной памяти для данных одного процесса (sqlservr в нашем случае) не превышает 3 GB, то при превышении размера базы данных значения в 30 – 50 GB целесообразно переходить на 64 – разрядные технологии. На данный момент можно использовать сервера, основанные на процессорах Intel Itanium 2 или ждать выхода операционной системы Windows, использующей возможности новых процессоров Intel с технологией EM64T.

Для стоек дисковых RAID массивов можно использовать продукты, основанные на интерфейсе SCSI или FC (Fibre Channel). Несмотря на то, что интерфейс FC имеет более высокую пропускную способность, узкое место при интенсивных дисковых операциях, скорее всего, проявится на физических ограничениях винчестеров RAID массива по обработке запросов типа чтение – запись. Т.е. при небольшом количестве винчестеров, входящих в RAID массив, значительного увеличения производительности дисковой подсистемы FC в сравнении с SCSI в целом ожидать не стоит. Ситуация меняется в пользу FC только по мере увеличения общего количества винчестеров, входящих в RAID , кроме того, стойки FC могут также динамично масштабироваться в стеке или с использованием внешних FC коммутаторов.

Принципиальное преимущество решений, основанных на FC в том, что к одной дисковой стойке можно подключить несколько серверов, в частности, можно организовать кластер серверов Windows на одной дисковой подсистеме. Соответственно, на продуктах FC можно организовать принципиально более надежное решение, возможный пример которого показан на втором рисунке предыдущего раздела.

Для производительности баз данных очень важен выбор типа RAID массива. Довольно часто используемый тип RAID 5 для эксплуатации рабочей базы данных является неудачным решением. Это связано с тем, что массивы RAID 5 не очень хорошо работают на массовых запросах на запись данных.

Файлы данных, лог транзакций, temp DB, backup лучше разносить на раздельные дисковые массивы.

Некоторые рекомендации по применению RAID массивов для баз данных Axapta:

Чем больше винчестеров входит в RAID массив, тем выше его производительность. Поэтому, например 4-м дискам емкости 146 GB лучше предпочесть 8 дисков емкостью 73 GB.

Неоднозначный вопрос, что лучше, например два небольших RAID массива с разнесенными файловыми группами базы данных или один с большим количеством винчестеров в своем составе.

При проектировании операций ввода - вывода для баз данных необходимо стремиться, чтобы на одном RAID массиве не появлялись одновременно крупные операции чтения – записи, например, не стоит делать backup на том же RAID, где лежит вся или часть базы данных, даже если свободное пространство это позволяет. В этом случае продуктивная производительность дисковой подсистемы резко падает.

 

4.3. Сервер приложений

Для сервера приложений системы Axapta наиболее важным параметром является мощность процессоров.

Хорошо себя зарекомендовали двухпроцессорные машины на процессорах Xeon.

Ни в коем случае не стоит совмещать AOS и SQL Server на одном и том же физическом сервере. Причина не только в производительности, но и в пониженной надежности подобной связки. Сервис AOS в сравнении с SQL Server более подвержен возможным сбоям, поэтому для крупных систем Axapta целесообразно построить кластер AOS.

Кластер серверов приложений возможен по технологии Windows и по технологии AOS.

В случае реализации кластера не обеспечивается отказоустойчивость текущих соединений, т.е. в случае отказа одного из серверов приложений активным пользователям необходимо заново войти в систему.

Кластер AOS обеспечивает также простую дифференциацию нагрузки на активные доступные серверы в кластере.

В первом приближении, можно рассчитывать нагрузку до 60 – 80 активных сетевых соединений на один двухпроцессорный сервер приложения.

В отличие от сервера баз данных, в настоящий момент внедрение 64 – разрядных технологий не принесет преимущества в производительности серверу приложения Axapta .

 

4.4. Сетевые соединения

Трезвенная архитектура системы Axapta весьма нетребовательна к пропускной способности локальной сети между сервером приложений и клиентом. Но здесь есть существенный подводный камень. Для комфортной работы пользователей необходимо сетевое соединение с низким временем задержки (latency). Несмотря на то, что Technet рекомендовал время отклика не более 50 мсек, комфортная работа возможна в случае задержки не более 10 - 15 мсек.

По анализу практического опыта, канала с честной пропускной способностью 2 Mbit может быть вполне достаточно для комфортной работы порядка 20 конкурентных пользователей.

По возможности, необходимо стремиться обеспечить условия доступа пользователей в режиме с характеристиками ЛВС (local area network), иначе не избежать организации терминального доступа для клиентов Axapta. Терминальное решение менее предпочтительно в сравнении с прямым соединением клиента с AOS, так как в этом случае гораздо труднее организовать режим надежного доступа.

Также важно обеспечить минимальное возможное время отклика между сервером баз данных и сервером приложения. Здесь лучше всего использовать прямое Gigabit Ethernet соединение серверов с выделенными IP адресами, минуя коммутаторы ЛВС.

 

5. Процедуры обеспечения надежности Microsoft Axapta

В этом разделе представлены элементы подхода к организации процедур сопровождения, прямо влияющих на состояние надежности системы Axapta. Все рекомендации успешно опробованы на практике, но, конечно же, здесь могут быть и другие альтернативные решения.

К проектированию организационных процедур необходимо применять подход, учитывающий уникальные условия конкретного предприятия.

 

5.1. Организация Service Desk и процесса управления инцидентами

Как уже подробно говорилось выше, служба Service Desk и управление инцидентами лежит в основе всех процессов сопровождения.

Рассмотрим полный цикл приема и обработки инцидентов. Разумно его реализацию распространить на полный спектр услуг отдела IT, а не только на цели сопровождения ERP – системы.

Организация Service Desk

IDB – incident database (база данных инцидентов ITIL )

В зависимости от сущности поступившего инцидента его обработка и решение может быть выполнено на самых ранних шагах 1 и 2. Например, на запрос удаленного пользователя о проблеме, связанной с зависанием при переключении раскладки клавиатуры в Axapta, оператор Service Desk может сразу отправить ссылку на документ с фиксом, решающим эту ошибку.

Шаг 1.1. Прием и регистрация инцидента

Входные данные: Письменное или устное сообщение об инциденте, требующем рассмотрения отделом IT

Описание процесса: Клиент осуществляет обращение в службу Service Desk по телефону или по электронной почте на выделенный почтовый ящик 911.

Оператор Service Desk принимает запрос и, в случае отсутствия немедленного ответа, заносит информацию об инциденте в IDB , при этом, он сообщает клиенту номер инцидента и информирует о принятии инцидента к рассмотрению. Телефонные обращения регистрируются в IDB и, соответственно, обрабатываются далее только в случае совершенно понятной ситуации с проблемой, например, если она возникала ранее. В противном случае необходимо требовать от клиента письменный запрос с описанием инцидента.

Регистрации подлежат все обрабатываемые запросы кроме повторных обращений, относящихся к одному инциденту. При выявлении повторного обращения оператор сообщает клиенту номер уже зарегистрированного инцидента и его текущий статус.

Регистрации не подлежат тривиальные вопросы, на которые может оперативно ответить оператор Service Desk.

При заведении новой записи инцидента оператор Service Desk вносит следующие регистрационные данные:

  • Контактное лицо (Фамилия)
  • Подразделение обратившегося пользователя
  • Краткое описание инцидента
  • Способ обращения (телефон, e-mail)

Требования по качеству: Обязательно вежливое рассмотрение всех обращений. Необходим быстрый ответ клиентам без регистрации инцидентов на простые вопросы, находящиеся в компетенции оператора Service Desk . Необходимо немедленно при регистрации инцидента внести новую запись в IDB и информировать клиента об ее номере. В случае проявления признаков конфликта с клиентом обязательно информирование об этом руководителя службы Service Desk .

Выходные данные: новая регистрационная запись инцидента в IDB

Шаг 1.2. Классификация, начальная поддержка, перенаправление инцидента

Входные данные: Зарегистрированный инцидент

Описание процесса: Оператор Service Desk проводит классификацию инцидента по категории.

По возможности, оператор Service Desk , самостоятельно решает возникший инцидент. В случае если нет возможности самостоятельного решения инцидента, информация об инциденте переправляется соответствующему ответственному сотруднику отдела IT или в консалтинговую компанию (эскалация инцидента). Выбор ответственного сотрудника необходимо осуществлять в соответствии с документом " Критерии выбора специалиста по решению инцидента ".

При перенаправлении инцидента необходимо выяснить ожидаемое время (дату) его решения и внести в IDB следующие данные:

  • Планируемая дата решения
  • Ответственный сотрудник за решение
  • Изменить статус инцидента на "решается"

Требования по качеству: Данный этап необходимо выполнить без временных задержек. Оператор Service Desk должен самостоятельно решить инциденты, находящиеся в его компетенции. При перенаправлении инцидента необходимо правильно определить ответственного специалиста по решению инцидента. Требуется аккуратность и точность при регистрации приведенных выше данных об инциденте.

Выходные данные: изменение данных регистрационной записи об инциденте в IDB

Шаг 1.3. Решение инцидента

Входные данные: Информация об инциденте

Описание процесса: Решение проблемы, связанной с инцидентом принимает ответственный специалист отдела IT или внешней консалтинговой компании. В ходе решения данный специалист должен самостоятельно контактировать с клиентом.

В случае если на решение инцидента недостаточно времени ответственный специалист должен самостоятельно сообщить оператору Service Desk информацию о продлении срока решения и причинах, вызвавших продление срока. Оператор Service Desk вносит пояснения в поле "Подробное описание инцидента".

После решения инцидента ответственный специалист информирует об этом оператора Service Desk .

Требования по качеству: Ответственный специалист, решающий инцидент, обязан вовремя информировать оператора Service Desk о продлении срока решения и причинах, его вызвавших, а также о самом факте успешного решения.

Выходные данные: Сообщение о решении инцидента

Шаг 1.4. Закрытие инцидента

Входные данные: Сообщение о решении инцидента

Описание процесса: Оператор Service Desk запрашивает клиента подтверждение о решении инцидента (если оно не было получено ранее).

В случае если инцидент решен, в IDB статус инцидента меняется на "решено", если клиент тестирует решение или не может ответить (например, по причине занятости и т.п.), статус меняется на "тестирование".

В случае если клиент опровергает информацию о решении инцидента, необходимо о данном факте сообщить руководителю службы Service Desk и в IDB для записи инцидента проставить статус "тестирование"

Требования по качеству: После получения информации о решении инцидента оператор Service Desk должен немедленно запросить подтверждение об его решении от клиента. Обязательно корректное проставление статуса инцидента на "тестирование" или "решено".

Выходные данные: Закрытие инцидента (установка статуса "решено") в IDB

 

5.2. Резервное копирование

Отлаженная схема резервного копирования рабочей базы данных – вещь абсолютно необходимая для любого предприятия. Конкретная схема резервного копирования может быть различной. Планирование, внедрение и поддержка зависит от жесткости требований к восстановлению данных, режима работы предприятия, размера базы данных, имеющихся ресурсов.

Одна из возможных схем резервного копирования для небольшой (до ~50 GB) базы данных может быть следующей:

Схема резервного копирования

Ежедневный полный backup с сервера SQL 1 осуществляется на сервер SQL 2 - массив "А". Туда же осуществляются перенос получасовых логов транзакций.

На массиве "В" производится накатывание логов транзакций на резервную standby версию рабочей базы данных.

Ежедневно копия backup переносится на ленту накопителя Ultrium .

В данной схеме возможны три последовательных уровня восстановления базы данных:

Разумно время от времени (раз в год) проводить учебную тревогу по восстановлению архивных данных. Также это обязательно нужно делать при существенном изменении существующей или внедрении новой схемы резервного копирования.

Целесообразно вместе с данными SQL Server архивировать также и актуальное приложение Axapta.

 

5.3. Служебные операции с базой данных

Необходимость периодических служебных операций с базой данных Axapta не столь очевидна. В принципе, для небольшого размера базы данных, SQL Server и Axapta могут устойчиво совместно работать достаточно длительное время. Тем не менее, если график гарантированной доступности системы Axapta позволяет периодически (один раз в неделю, один раз в месяц) проводить с базой данных служебные операции, то лучше их предусмотреть в расписаниях Jobs SQL Server .

Служебные операции в Job могут быть следующие:

В случае крупной базы данных для сокращения времени исполнения служебных процедур можно расщепить расписание, исключив из него одну или несколько крупных таблиц (например, inventsettlement) и сформировав новое расписание отдельно для данных таблиц.

 

5.4. Мониторинг критериев надежности

Это очень важная процедура контроля надежности, входящая в процесс управления уровнем сервиса. На ней основан анализ и технологический фокус проектирования решения Axapta, функционирующего на предприятии.

Процедура контроля надежности

Первая задача – определить допустимые показатели критериев надежности.

Разумеется, т.к. на процесс обеспечения надежности требуется адекватное выделение соответствующих ресурсов, то все показатели должны быть документально согласованы с руководством предприятия. Также все показатели должны быть реально достижимы, иначе предварительно необходимо реализовать специальный проект с целью их достижения. Ответственный за реализацию этапа определения и утверждения допустимых показателей надежности – руководитель отдела IT.

Для критерия доступности принимаем желаемый гарантированный период доступности системы Axapta , например с 8:00 по 20:00 часов семь дней в неделю и, собственно, сам показатель, например 99.5%, измеряемый на протяжении каждого календарного месяца.

Для критерия безошибочности принимаем максимально допустимое количество открытых ошибок, связанных с ущербом выполнения основных бизнес – процессов, например, пять.

Для критерия производительности определяем допустимые показатели индексов по категориям, представленным в разделе 2.3. Основанием для определения индексов могут быть реальные операции в системе и отчеты, но, иногда, лучше подготовить отдельные специальные тестовые операции и отчеты, обработка которых не должна зависеть от внешних условий запуска. Для каждой категории вполне достаточно определить не более двух - трех индексов. Пример:

Индекс

Измерение

Допустимое значение

1

Время открытия формы "Заказы"

сек.

3

2

Скрипт, моделирующий цикл ввода и обработки заказа

строк заказа / мин.

200

3

Скрипт, моделирующий последовательный расчет трех наиболее популярных отчетов с типичными условиями выборки

мин.

10

4

Время операций A: reindex, B: shrink, C: checkdb

GB / мин.

A: 1, B: 2, C: 3

Мониторинг доступности ведется ежедневно администратором БД Axapta (см. роли в разделе 3.3). Мониторинг (аудит) безошибочности и производительности достаточно проводить один раз в месяц системным аналитиком. Ответственный за контроль качества выполнения этой процедуры - руководитель отдела IT.

На основании сравнения эталонных и фактических показателей надежности производится анализ существующих тенденций. Анализ нужно проводить в широком временном диапазоне и с учетом исходных причин отклонений, т.к. возможны случайные флуктуации показателей. Например, если в серверном помещении по внешним причинам на сутки было отключено электричество, это конечно привело к полному срыву соглашения о доступности, но такой форс-мажор не свидетельствует о наличии проблем с доступностью в самой системе Axapta.

Анализ тенденций и возможных проблем проводит системный аналитик. По мере необходимости в анализе принимают участие другие профильные специалисты отдела IT, а также могут привлекаться специалисты внешних консалтинговых компаний.

Проанализировав тенденции и определив корневые причины, их породившие, можно приступить к проектированию и планированию корректирующих решений, если этого требуют результаты анализа и намечается отклонение от эталонных показателей. "Хорошей" причиной планирования изменений может быть желание или необходимость повысить эталонный уровень качества и надежности системы Axapta. Работа по проектированию актуальных решений может выполняться ролью системного аналитика, но общая ответственность по их планированию к реализации лежит на руководителе отдела IT.

Реализация разработанных решений, по крайней мере, крупных, должна проходить через процесс управления изменениями и релизами. Здесь очень важно также проводить анализ результатов внедрения (PIR), чтобы оценить эффект от результатов внедрения. Очень хорошо, если для анализа можно использовать независимого компетентного аналитика. Этот PIR кроме своего прямого назначения может также с успехом использоваться для внутренних PR акций на предприятии, но ни в коем случае не нужно ассоциировать PIR с некоей внешней "историей успеха", потому что анализ результатов изменений должен быть честным.

 

Заключение

По многим причинам очень сложно проектировать и реализовывать инфраструктурные проекты, основной целью и результатом выполнения которых является не внешний громкий результат, а внутреннее качество . Далеко не всегда удается успешно завершить задуманное, но если несмотря ни на какие внешние условия есть желание поставить и стремиться к целям постоянного улучшения системы, успешный результат обязательно проявится. Надеюсь, что данная статья будет полезна для достижения цели высоконадежного режима работы Microsoft Axapta. 

С уважением, автор

Сергей Котов, serge_kotov@mail.ru