4. Принцип деления Цодов

Условно разбив ЦОДы по степени бесперебойности предоставления IT- услуг, получим три принципиально разные группы. К первой отнесем ЦОДы, незапланированный простой которых в течение более 5 минут в год ведет к катастрофическим последствиям для бизнеса предприятия. Ко второй — от 5 до 500 минут (это примерно один восьмичасовой рабочий день) в год. К третьей — все остальные. Получится следующая пирамида: ее вершину (менее 1%) составят заказчики, для бизнеса которых бесперебойная работа IT-инфраструктуры в высшей степени важна, среднюю часть займут те, для кого она критически важна, а в основании окажутся компании, чей бизнес нуждается в IT.

Начнем с вершины. Первый катастрофоустойчивый ЦОД был запущен в эксплуатацию в 2002 году. С тех пор аналогичных центров в нашей стране появилось немало. На эту тему было написано достаточное количество статей, в которых говорится примерно об одном и том же. Что, впрочем, не удивительно, поскольку технический подход к построению катастрофоустойчивого ЦОДа за это время остался неизменным: специализированные кластерные программные средства и системы репликации данных в оперативном режиме базируются на серверах и системах хранения данных, расположенных в высокопроизводительной сети хранения данных (SAN). Еще надо быть готовым к организации второй площадки на удалении не менее 10 км от первой (в hi-end-решении для арбитрации организуется отдельная площадка) для обеспечения более устойчивой работы. В данном случае чем больше расстояние между центрами, тем лучше обеспечивается защита от стихийных бедствий. Креация катастрофоустойчивого ЦОДа практически всегда сопровождается профессиональными консалтинговыми услугами по организации бесперебойных бизнес-процессов, поэтому к техническим составляющим (оборудованию и программным средствам) добавляются тома регламентов и инструкций, определяющих порядок действий персонала при наступлении «страхового случая». Все прекрасно, все работает. Остается одна проблема — высокая стоимость владения: в среднем креация одного проекта обходится в 300–400 млн руб. Принятие решения о внедрении катастрофоустойчивого ЦОДа должно базироваться на сравнении, когда на одной чаше весов сумма, в которую обходится простой, а на другой — стоимость креации и экзистенции катастрофоустойчивого решения. При расчете стоимости простоя должны учитываться прямые и косвенные составляющие. И если прямые убытки посчитать достаточно просто, то оценить, например, потерю бизнес-репутации далеко не всегда удается сразу и точно. Экзистенция катастрофоустойчивого ЦОДа — это регулярные учения и адаптация регламентов на основе проведенных учений, и снова учения. Иначе необученный персонал не будет знать, что нужно делать в критической ситуации. С точки зрения техники и пользователя все должно пройти незаметно: современные кластерные программные средства восстанавливают работу в течение минуты на любой операционной системе, но для IT-персонала это время четких и слаженных действий.

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