Чтобы компания всерьез озаботилась непрерывностью своего бизнеса, вовсе не обязательно дожидаться критического сбоя в работе ИТ. Как правило, любой ИТ-менеджер прекрасно сознает важность резервирования мощностей и дублирования инфраструктурных решений. Вопрос чаще всего упирается в обоснование необходимых инвестиций, которое сможет убедить топ-менеджмент и владельцев, и тут многое будет зависеть от аргументов, предъявляемых ИТ-руководством. Известны случаи, когда для усиления эффекта первым лицам компании демонстрировалась видеозапись пожара в серверной комнате, после чего необходимые средства мгновенно выделялись.
Существуют и менее радикальные, но тоже весьма убедительные аргументы, актуальные для динамично развивающейся компании. Очевидно, что когда речь идет о централизации приложений, то необходимо серьезно относиться к инфраструктуре, обеспечивающей работу бизнес-систем. Риски, связанные с ее работоспособностью, становятся критическими, и поэтому требования к ее надежности и отказоустойчивости выходят на совершенно иной уровень.
База для консолидации
Когда в конце 2006 года компания «Балтика» объединилась с тремя другими пивоваренными компаниями — «Вена», «Ярпиво» и «Пикра», у нее появилось десять производственных площадок, разбросанных по всей стране, и более 60 удаленных офисов. Несмотря на то, что юридические лица формально остались разными, собственник стал общим. Вполне естественным образом возникла потребность в совместной работе сотрудников и унификации бизнес-процессов компаний.
«После того как компания увеличилась в размере практически в два раза, поменялась и ее ИТ-стратегия», — рассказывает Илья Тамбовцев, руководитель отдела развития информационной инфраструктуры компании «Балтика». Во-первых, необходимо было обеспечить единое информационное пространство для работы всех сотрудников. Кроме того, весьма актуальной стала унификация ИТ-сервисов. Сотрудник в Хабаровске, Санкт-Петербурге или Туле должен обладать примерно одинаковым инструментарием для работы с информацией. Второе серьезное изменение в ИТ-стратегии — акцент на обеспечение доступа к корпоративным системам и информационным ресурсам с разных площадок и из Internet, это особенно важно для сотрудников, находящихся в командировках, и мобильных сотрудников, по роду работы переезжающих с места на место.
Было нужно также обеспечить информационное взаимодействие с партнерами: ранее ИТ-системы развивались в рамках отдельных заводов и были в меньшей степени ориентированы на обмен информацией между собой. Теперь же в стратегии расширен спектр возможных пользователей информационных систем: среди них не только сотрудники, но и партнеры — дистрибьюторы и поставщики.
Такие изменения во взглядах на ИТ продиктовали важное требование — объединить девять локальных ERP-систем на базе «Монолит SQL» в единую корпоративную систему. Этот шаг позволял организовать единые бизнес-процессы, мгновенный обмен информацией, оперативную аналитику, а также упростить дальнейшее наращивание функционала системы. Именно решение о консолидации ERP-систем повлекло за собой цепочку весьма важных проектов, главным из которых стало построение отказоустойчивого ЦОД.
У компании до сих пор не возникало проблем с непрерывностью бизнеса, и меры в этой сфере были приняты с прицелом на перспективу. Если ранее технические характеристики позволяли ИТ-специалистам говорить о готовности инженерных систем на уровне 99%, то при централизации информационных систем этот показатель был признан недостаточным.
В штаб-квартире «Балтики» к тому времени уже существовали два ЦОД, обслуживавших локальные бизнес-процессы. Первый из них появился в 1997 году и оставался единственным до 2005 года. Его назначением было обслуживание штаб-квартиры, и он был небольшим: пять серверных шкафов вмещали до 30 серверов. Второй ЦОД был создан в 2005 году и расширен в 2006-м, в том числе в связи с объединением компаний.
По принципу построения они сильно отличались друг от друга. Первый создавался оперативно и представляет собой набор шкафов и систем охлаждения. Он соответствовал потребностям бизнеса, существовавшим на тот момент. Второй ЦОД строился уже с учетом объединения: компании были необходимы дополнительные места для размещения нового серверного оборудования. Тем не менее в его реализации не было целостности — он представлял собой набор решений по шкафам, охлаждению и энергоснабжению.
Существовавшие ЦОД не вызывали нареканий по работоспособности, однако их катастрофически не хватало для развития информационных систем. Была очевидна необходимость построения третьего ЦОД с повышенными требованиями по надежности.
Третий, но не лишний
Требования к создаваемому ЦОД напрямую определялись требованиями бизнеса к информационным системам. В первую очередь необходимо обеспечить непрерывное функционирование центральных ИТ-приложений — базовых, от которых зависит работа остальных, и приложений, физически развернутых в штаб-квартире с предоставлением удаленного доступа к ним с остальных площадок. В обоих случаях работоспособность таких приложений критически важна для компании. Непрерывность же функционирования и бизнес, и ИТ понимают в данном случае одинаково, причем в прямом смысле: речь идет о круглосуточной бесперебойной работе.
Другим требованием стало обеспечение доступности и нормальной производительности бизнес-приложений при нагрузке до 3 тыс. пользователей. «Мы считаем, что это пиковая нагрузка, учитывая, что производственные площадки располагаются в различных временных поясах», — поясняет Тамбовцев. Когда на европейской территории России рабочий день начинается, на Дальнем Востоке он уже завершается.
Таким образом, требования бизнеса в первую очередь подразумевали отказоустойчивость решений. Этого, в первую очередь, можно достичь избыточностью мощностей и территориальным разнесением дублирующих компонент разных приложений. Кроме того, необходимо обеспечить высокую готовность инженерной инфраструктуры. Например, кондиционеров должно хватать для охлаждения оборудования даже в случае выхода одного из них из строя, а поломка одного из вентиляторов кондиционера не должна блокировать работу всего устройства. Зарезервированы должны быть и наружные инфраструктурные сервисы, в первую очередь электропитание.
Наконец, важным требованием со стороны ИТ было обеспечить комплексный мониторинг всех компонент инфраструктуры. Избыточность не является панацеей, когда выход из строя какой-либо из компонент остается незамеченным.
Третий ЦОД, запущенный в конце 2007 года, имеет площадь 35 кв. м и может обслуживать 10—11 шкафов и до 80 серверов. В его основу легли решения компании АРС: в числе прочего в состав установленного оборудования вошли ИБП Symmetra PX мощностью 60 кВт, девять шкафов NetShelter SX 42U 600 мм, система кондиционирования на базе четырех In Row RC Chilled Water, InfraStruXure Manager, а также APC Environmental Manager с датчиками мониторинга температуры и влажности, располагающихся внутри шкафов.
Требуемая отказоустойчивость была достигнута благодаря системе с водяным охлаждением. Она включает в себя бак с водой массой 2 т и обладает существенной инерционностью: приемлемый уровень температуры удерживается около 40 минут при нагрузочной мощности около 60 кВт. Это позволяет в случае полного отключения электроэнергии использовать резервные батареи только для питания серверного оборудования и водяной помпы. Заряда батарей хватает на 45 минут работы. В противном случае, если бы такой инерционной системы для данного помещения и при такой нагрузке не было, пришлось либо сократить время работы серверного оборудования до полного отключения до четырех минут, либо значительно увеличить число аккумуляторных батарей, либо использовать иные решения для охлаждения.
Через 20 минут работы ЦОД в автономном режиме происходит отключение серверов, поддерживающих наименее критичные приложения, через 30 минут останавливается ERP-система, а через 35 минут — все остальные инфраструктурные решения. «Мы не желаем форс-мажора, при котором бы пришлось на практике применять разработанную схему приоритетов, но деятельность файл-серверных приложений, корпоративного портала, почты и документооборота гораздо менее критична, чем стабильная работа ERP-системы», — констатирует Тамбовцев. Стоит отметить, что в решении не используются дизельные генераторы, так как на заводе в Санкт-Петербурге существует собственная газотурбинная станция высокой мощности.
В настоящий момент все ЦОД связаны между собой по магистралям, проложенным различными маршрутами и объединены в единое коммуникационное ядро с пропускной способностью 4 Гбит/с. Находясь на одной производственной площадке, они в то же время территориально разнесены: расстояние между ними составляет от 300 до 600 м. Это обеспечивает минимальные требования по катастрофоустойчивости. «Разумеется, от крупных природных катаклизмов это не защитит, но в случае аварии в одной из серверных обеспечивает изоляцию остальных», — уверен Тамбовцев. Наименее современный ЦОД в настоящий момент выполняет роль телекоммуникационного узла локальной сети производственной площадки, критически важные бизнес-приложения в нем не развернуты.
Целостное решение
Проект создания нового ЦОД оказался весьма длительным: он растянулся более чем на год. Во многом это произошло из-за желания компании обеспечить надежность за счет единого сбалансированного решения. Технические требования к создаваемому центру были определены и структурированы в августе 2006 года.Затем в течение месяца происходил поиск подходящего помещения на территории штаб-квартиры. В условиях работающего предприятия с высокой плотностью использования площадей это нелегкая задача, тем более что в помещении необходимо разместить не только серверы, но и все вспомогательное оборудование. В октябре 2006 года было произведено предварительное проектирование для того, чтобы определиться со стоимостью решения и возможными вариантами его реализации.
После защиты необходимых вложений на инвестиционных комиссиях было начато детальное проектирование. До февраля 2007 года решение согласовывалось со строительными и инженерными службами. Сами строительные работы начались в мае, а в августе было смонтировано оборудование. После проведенного в октябре 2007 года тестирования ЦОД был сдан в эксплуатацию.
Процесс тестирования был весьма любопытным. Поскольку тестирование инженерных систем на дорогом оборудовании посчитали неразумным — кощунственным и рискованным по деньгам, для этих целей были приобретены тепловые пушки. Тестирование проводилось как в условиях имитации экстремальной работы, так при отключении электропитания.
В ходе проекта весьма сложным оказалось скоординировать деятельность внешних партнеров по проекту и служб компании «Балтика»: строительных и инженерных служб, службы безопасности, службы водоснабжения и канализации. «У коммунальных служб свои подрядчики, у ИТ-службы — свои, но в качестве результата необходимо получить целостное решение, включающее не только инженерную, но и всю вспомогательную инфраструктуру», — подчеркивает Тамбовцев. Уже на начальном этапе нужно было включать в проектную группу представителей всех вспомогательных служб, вовлекая их таким образом в проект и дав возможность ощутить его важность. К сожалению, осознание этого появилось лишь ближе к концу проекта.
Другой сложность весьма неожиданно стал вопрос доставки оборудования на место монтажа. Увы, логистические моменты редко прорабатываются изначально, но они способны стать серьезным препятствием на пути реализации проекта. Площади штаб-квартиры плотно заполнены производственным оборудованием, и доставка аппаратуры для ЦОД превратилась в нетривиальную задачу. Отдельную проблему представлял монтаж оборудования на крыше производственного корпуса. Технику пришлось поднимать туда практически вручную — варианты использования подъемных кранов и вертолетов оказались нереализуемыми.
Еще одним непредвиденным фактором стало то, что расчет необходимого энергообеспечения и охлаждения производился без учета лезвийных технологий, требующих как большей электроэнергии, так и большего охлаждения. Сейчас при заполнении ЦОД современными серверами приходится помнить об ограничении в 65 кВт и распределять оборудование равномерно.
ИТ без экстрима
Финансирование проекта и его защита перед бизнес-менеджментом стали важной составляющей успеха. Руководство осознавало, что для обеспечения круглосуточной работы информационных систем необходимы значительные инвестиции в надежность инфраструктуры. «Разумеется, мы всегда предлагаем оценивать соотношение цены и качества, но говорим и о рисках, связанных с выходом из строя систем. Осознание руководством рисков способствует выбору оптимального решения», — уверен Тамбовцев.
В данном случае фактически стоял выбор между копированием принципов построения второго ЦОД и созданием более дорогого, но и более надежного. Важную роль в выборе сыграло то, что именно отказоустойчивость была главным требованием к разрабатываемому решению. «Мы нашли не самое дорогое, но вполне надежное решение от известного на рынке поставщика, подходящее под наши требования», — характеризует сделанный выбор Тамбовцев.
У «Балтики» есть несколько ИТ-партнеров, возможности и компетенции которых хорошо известны. Построение ЦОД было доверено компании «Комплит», хотя у нее и не было компетенций по конкретному решению, так как использование водяной техники охлаждения в серверной инфраструктуре являлось на тот момент оригинальным решением. Разумеется, применение новшеств сопровождается рисками, снижающими надежность решений. Чтобы избежать этого, было организовано несколько визитов на стенд компании АРС в Москве. Но все же лишь окончательное тестирование подтвердило надежность решения и развеяло опасения.
Кроме того, компаниям, осуществляющим централизацию бизнес-систем, необходимо помнить, что важно не просто добиться отказоустойчивости, но и обеспечить инфраструктуру доступа к приложениям. В случае «Балтики» это означало необходимость проекта по организации терминального решения и защищенного доступа через Internet с использованием технологий Citrix и RSA. Удаленный доступ осуществляется с помощью двухфакторной идентификации: традиционной пары «имя пользователя — пароль», а также ключа с физического носителя. Помимо этого, централизация ERP потребовала объединения предприятий в единый домен Microsoft Active Directory с единой политикой и правилами. Это позволит добиться того, чтобы пользователи не просто имели стабильный доступ к своим рабочим местам, но и чтобы простои в их работе были минимальны.
По оценке Тамбовцева, если информационные системы компании остановятся на час, то без серьезных финансовых потерь удастся обойтись, хотя, разумеется, каждый такой инцидент крайне неприятен. Потери возникнут, если работоспособность не будет восстановлена в течение целого рабочего дня. Очевидно, что на ERP-систему возложена функция обеспечения отгрузок товара. Далее прослеживается прямая связь между отгрузками и арендой автотранспорта, загрузкой складов и производством, а также штрафами за невыполненные обязательства.
Как известно, человек может какое-то время прожить без воды и еды. Бизнес также может некоторое время обходиться без ИТ. «Разумеется, в обоих случаях крайне желательно таких экстремальных испытаний избежать», — резюмирует Тамбовцев. Гораздо проще прогнозировать развитие требований бизнеса и выстраивать инфраструктуру в соответствии с ними.