Вероятностный подход к проектированию центров обработки данных
Алексей Жумыкин опубликовал 2 августа 2012 | |
Недавние остановки сервисов Amazon, Blackberry и других крупных игроков IT-индустрии спровоцировали в зарубежной прессе волну обсуждений об этичности применения бизнес-кейсов при планировании надежности ЦОД компаний такого уровня. В качестве примера можно привести вот эту . И большинство аудитории придерживается точки зрения, что владельцы не должны останавливаться ни перед какими затратами для обеспечения максимально возможной доступности сервиса, и, тем более, намеренно закладывать в бизнес-план простои сервиса.
С подобным подходом можно отчасти согласиться. Однако, в противовес общественному мнению, нельзя забывать, что ЦОДы – это также коммерческие предприятия, которые должны иметь свою норму прибыльности, капитальные и операционные бюджеты и тому подобные атрибуты живого бизнеса.
Учитывая растущий спрос на услуги ЦОД, ниша центров, предлагающих фактическую доступность намного меньше той, которую обещают сегодня маркетинговые обещания по всему миру, будет еще долго велика. Поэтому задача заказчика – грамотно оценить свои потребности в доступности сервисов, а задача владельцев ЦОД – соответствовать этим потребностям при одновременной минимизации рыночной стоимости.
Найти свой путь, разрываясь между стремлением заявить высокий Tier и, в то же время, сохранить бюджет проекта на приемлемом уровне поможет подход к проектированию, описанный ниже. Хочется отметить, что, несмотря на десятки публикаций на данную тему, описание подобной методики не встречалось мне еще ни разу. Между тем, для успешного воплощения ее в жизнь нужны лишь минимальное владение теорией вероятности, понимание применяемых технологий и немного здравого смысла. В качестве урожая можно расчитывать на максимально эффективное, с точки зрения обеспечения повышения доступности сервисов, вложение инвестиций.
Сразу оговоримся, что решения, использованые ниже, носят не рекомендательный, а иллюстративный характер, и их не стоит рассматривать в качестве примеров эффективных схем электроснабжения, равно как и в качестве бюджетной оценки затрат реального проекта. Для простоты мы рассмотрим только электрическую часть, хотя, очевидно, что этот же алгоритм можно применять для любых других систем ЦОД. Впрочем, и не только ЦОД.
Вариант 1. Наращивание мускулов
Итак, рассмотрим нагрузку, которой, в нашем случае, будет являтся машинный зал, подключенную к одному источнику питания Т1.
Прочитав договор на электроснабжение, можно найти в нем то, что поставщик обеспечивает бесперебойную поставку электроэнергии, однако, ссылается на необходимость проведения плановых профилактических работ на трансформаторной подстанции, которые не превысят суммарно 48 часов год. А вспоминая аварию в Петербурге 2010 года, можно заложить в план риск остаться без электричества на 2 дня. Также, непредвиденный ремонт источника может затянуться на время, необходимое для поставки вышедшего из строя компонента. Будем оптимистами, и отведем на ремонт 14 дней. О реальных сроках поставках запасных частей для подобной техики Вы можете самостоятельно осведомиться у местных дистрибьютеров.
В итоге получается следующая картина.
|
Вариант 1
|
Плановое TO, дни
|
Авария, дни
|
Ремонт, дни
|
Итого, недоступность, %
|
Итого, недоступность, часов
|
Доступность, %
|
| T1 |
2
|
2
|
14
|
|||
| % времени недоступности Т1 |
0,548%
|
0,548%
|
3,836%
|
4,93%
|
432,00
|
95,068%
|
Попытаемся улучшить ситуацию, добавив в систему второй источник питания. Это поможет нам практически устранить влияние планового ТО и существенно снизить опасность непредвиденного ремонта. В то же время, нам потребуется ввести коэффициент зависимости, отражающий вероятность недоступности второго источника, при условии недоступности первого. Примером здесь будет тоже веерное отключение в Петербурге в 2010 году. Даже если бы мы запаслись десятком источников питания от сети, напряжение в ЦОД не поступало.
Кстати, в данной схеме появляется другое слабое звено – АВР (автоматическое включение резерва). Очевидно, что надежность всей системы будет определяться надежностью самого слабого звена. Что и видно в таблице ниже:
| Вариант 1 | Плановое TO, дни | Авария, дни | Ремонт, дни | Итого, недоступность, % | Итого, недоступность, часов | Доступность, % |
| % времени недоступности Т1 | 0,548% | 0,548% | 3,836% | 4,93% | 432,00 | 95,068% |
| T2 | 2 | 2 | 14 | |||
| % времени недоступности T2 | 0,548% | 0,548% | 3,836% | |||
| Коэффициент зависимости Т1 и Т2 | 0 | 0,8 | 0,1 | |||
| Суммарный % времени недоступностиТ1 + Т2 | 0,003% | 0,441% | 0,384% | |||
| АВР | 1 | 14 | ||||
| % времени недоступности АВР | 0,274% | 3,836% | ||||
| Итоговый % времени недоступности Т1+Т2+АВР | 0,277% | 0,441% | 4,219% | 4,94% | 432,53 | 95,062% |
Усложним нашу схему еще больше, попытаемся исключить или минимизировать риск пропадания электроснабжения центра обработки данных от веерного отключения. Добавим в схему электроснабжения независимый источник — дизельный генератор.
Данная модель с использованием ДГУ и второго АВР имеет свои слабые стороны. А именно, необходимость довольно частого технического обслуживания ДГУ, что увеличивает эксплуатационные расходы. Также существует риск непоставки топлива в установленное время, что приведет к его остановке. В довершение «печальной» картины отметим, что подключается ДГУ к системе также через АВР, что по-прежнему влияет на надежность схемы в целом.
| Вариант 1 | Плановое TO, дни | Авария, дни | Ремонт, дни | Итого, недоступность, % | Итого, недоступность, часов | Доступность, % |
| Итоговый % времени недоступности Т1+Т2+АВР1 | 0,277% | 0,441% | 4,219% | 4,94% | 432,53 | 95,062% |
| ДГУ1 | 4 | 1 | 14 | |||
| % времени недоступности ДГУ1 | 1,096% | 0,274% | 3,836% | |||
| Коэффициент зависимостиТ1 + Т2 + АВР1 и ДГУ1 | 0 | 0 | 0 | |||
| Суммарный % времени недоступности Т1+Т2+АВР1 и ДГУ1 | 0,003% | 0,001% | 0,162% | |||
| АВР2 | 1 | 14 | ||||
| % времени недоступности АВР2 | 0,274% | 3,836% | ||||
| Итоговый % времени недоступности Т1+Т2+АВР1+ДГУ1+АВР2 | 0,277% | 0,001% | 3,997% | 4,28% | 374,55 | 95,724% |
Понятно, что надо слабое звено усилить. Не вдаваясь в технические подробности подключения, проанализируем, какие выгоды принесет нам резервирование второго АВР, который обеспечивает подключение резервного источника.
Как и можно было предположить, устранение самого слабого звена приводит к существенному повышению надежности системы. По крайней мере, 99% доступности сервиса мы обеспечили.
| Вариант 1 | Плановое TO, дни | Авария, дни | Ремонт, дни | Итого, недоступность, % | Итого, недоступность, часов | Доступность, % |
| Итоговый % времени недоступности Т1+Т2+АВР1+ДГУ1+АВР2 | 0,277% | 0,001% | 3,997% | 4,28% | 374,55 | 95,724% |
| АВР3 | 1 | 14 | ||||
| % времени недоступности АВР3 | 0,274% | 3,836% | ||||
| Коэффициент зависимости АВР2 и АВР3 | 0 | 0 | 0 | |||
| Суммарный % времени недоступности АВР2 и АВР3 | 0,001% | 0,147% | ||||
| Итоговый % времени недоступности Т1+Т2+АВР1+ДГУ1+АВР2+АВР3 | 0,004% | 0,001% | 0,309% | 0,31% | 27,50 | 99,686% |
А если нам нужно увеличить доступность? Проанализировав цифры, мы видим, что самым узким местом на данный момент является надежность ДГУ. Добавим резервный генератор, опять же, опустив технические моменты подключения.
В итоге, мы пришли к вполне приемлемой величине доступности сервиса, громоздкой схеме реализации и необъятному полю деятельности для дальнейших усовершенствований (читай: «затрат на услуги проектировщиков»). О стоимости внедрения решения поговорим чуть позже.
| Вариант 1 | Плановое TO, дни | Авария, дни | Ремонт, дни | Итого, недоступность, % | Итого, недоступность, часов | Доступность, % |
| Итоговый % времени недоступности Т1+Т2+АВР1 | 0,277% | 0,441% | 4,219% | 4,94% | 432,53 | 95,062% |
| ДГУ1 | 4 | 1 | 14 | |||
| % времени недоступности ДГУ1 | 1,096% | 0,274% | 3,836% | |||
| ДГУ2 | 4 | 1 | 14 | |||
| % времени недоступности ДГУ2 | 1,096% | 0,274% | 3,836% | |||
| Коэффициент зависимости ДГУ1 и ДГУ2 | 0 | 1 | 0,1 | |||
| Суммарный % времени недоступности ДГУ1+ДГУ2 | 0,012% | 0,001% | 0,384% | |||
| Коэффициент зависимости Т1+Т2+АВР1 и ДГУ1+ДГУ2 | 0 | 0 | 0 | |||
| Суммарный % времени недоступности Т1+Т2+ ВР1 и 2 ДГУ | 0,000% | 0,000% | 0,016% | |||
| Суммарный % времени недоступности АВР2+АВР3 | 0,001% | 0,147% | ||||
| Итоговый % времени недоступности Т1+Т2+АВР1+ДГУ1+ДГУ2+АВР2+АВР3 | 0,001% | 0,000% | 0,163% | 0,16% | 14,37 | 99,836% |
Вариант 2. Параллельное дублирование
Беглое прочтение стандартов построения ЦОД приводит к простой мысли: 2N лучше, чем N+1, и чем больше решений 2N применяется, тем выше Tier и тем надежнее ЦОД. Попробуем применить не последовательное, а параллельное резервирование источников питания.
Для сравнения приведем схему, позволяющую добится приблизительно такого же показателя доступности сервиса, как и в предыдущем случае.
И соответствующую ей таблицу рассчета вероятностей
| Вариант 2 | Плановое TO, дни | Авария, дни | Ремонт, дни | Итого, недоступность, % | Итого, недоступность, часов | Доступность, % |
| Т1 | 2 | 2 | 14 | |||
| % времени недоступности T1 | 0,548% | 0,548% | 3,836% | 4,93% | 432,00 | 95,068% |
| ДГУ1 | 4 | 1 | 14 | |||
| % времени недоступности ДГУ1 | 1,096% | 0,274% | 3,836% | |||
| АВР1 | 1 | 14 | ||||
| % времени недоступности АВР1 | 0,274% | 3,836% | ||||
| Суммарный % времени недоступности Т1+ДГУ1+АВР1 | 0,280% | 0,002% | 3,983% | 4,26% | 373,55 | 95,736% |
| Суммарный % времени недоступности Т2+ДГУ2+АВР2 | 0,280% | 0,002% | 3,983% | |||
| АВР3 | 1 | 14 | ||||
| % времени недоступности АВР3 | 0,274% | 3,836% | ||||
| Итоговый % времени недоступности Т1+ДГУ1+АВР1 и Т2+ДГУ2+АВР2 и АВР3 | 0,275% | 0,000% | 3,994% | 4,27% | 373,96 | 95,731% |
| АВР4 | 1 | 14 | ||||
| % времени недоступности АВР4 | 0,274% | 3,836% | ||||
| Коэффициент зависимости АВР3 и АВР4 | 0 | 0 | ||||
| Суммарный % времени недоступности Т1+ДГУ1+АВР1+Т2+ДГУ2+АВР2+АВР3+АВР4 | 0,001% | 0,147% | ||||
| Итоговый % времени недоступности схемы | 0,002% | 0,000% | 0,306% | 0,31% | 26,92 | 99,693% |
Видно, что кардинальных улучшений такой подход не принес, скорее наоборот, количество применяемого оборудования увеличилось. В подобной схеме следует ожидать повышения также инсталляционных расходов, так как при подобном расположении оборудования увеличится количество строительных работ и затрат на прокладку кабеля.
Вариант 3. Ищем выход
Как мы уже отметили раньше, игра в умножение вероятностей может оказаться увлекательной и весьма затратной для проекта. Гораздо полезнее взглянуть на исходные данные, и понять, что мы можем сделать в том или ином случае для уменьшения риска.
- Уменьшение времени планового ТО. Как правило, такой подход несет больше риска в долгосрочном периоде, хотя и может показаться привлекательным.
- Снижение времени веерного отключения. Без комментариев.
- Снижение риска недопоставки топлива. Этот вариант уже более близок к действительности. Подписание двух независимых контрактов на поставку, организация топливохранилища – вот только два из возможных решений.
- Снижение сроков поставки комплектующих. Конечно, можно договариваться с поставщиками и дистрибьюторами об организации регионального склада, однако это под силу только влиятельным заказчикам. Кроме того, таможенный барьер зачастую непредсказуем, и не позволяет быть в полной уверенности, что подобное решение будет эффективным.
В нашем случае решение может быть гораздо проще и красивее. Проанализировав, что самыми слабыми участками нашей схемы являются АВР, мы сделаем следующие шаги:
-
приобретаем дополнительный АВР каждого типа и отправляем его на наш склад.
-
проводим обучение обслуживающего персонала по экстренной замене любого модуля АВР в течение 24 часов путем изъятия со склада и установки вместо испорченного. В качестве элемента сравнения мы выберем первую схему.
В таком случае срок простоя из-за неисправности снижается с 14 до 1 дня. Какой эффект это будет иметь на доступность сервиса видно из таблицы.
| Вариант 3 | Плановое TO, дни | Авария, дни | Ремонт, дни | Итого, недоступность, % | Итого, недоступность, часов | Доступность, % |
| T2 | 2 | 2 | 14 | |||
| % времени недоступности Т1 | 0,548% | 0,548% | 3,836% | 4,93% | 432,00 | 95,068% |
| T2 | 2 | 2 | 14 | |||
| % времени недоступности T2 | 0,548% | 0,548% | 3,836% | |||
| Коэффициент зависимости Т1 и Т2 | 0 | 0,8 | 0,1 | |||
| Суммарный % времени недоступности Т1+Т2 | 0,003% | 0,441% | 0,384% | |||
| АВР1 | 1 | 1 | ||||
| % времени недоступности АВР1 | 0,274% | 0,274% | ||||
| Итоговый % времени недоступности Т1+Т2+АВР1 | 0,277% | 0,441% | 0,805% | 1,52% | 133,41 | 98,477% |
| ДГУ1 | 4 | 1 | 14 | |||
| % времени недоступности ДГУ1 | 1,096% | 0,274% | 3,836% | |||
| Коэффициент зависимости | 0 | 0 | 0 | |||
| Суммарный % времени недоступности Т1+Т2+ДГУ1 | 0,003% | 0,001% | 0,031% | |||
| АВР2 | 1 | 1 | ||||
| % времени недоступности АВР2 | 0,274% | 0,274% | ||||
| Итоговый % времени недоступности Т1+Т2+АВР1+ДГУ1+АВР2 | 0,277% | 0,001% | 0,305% | 0,58% | 51,08 | 99,417% |
| АВР3 | 1 | 0 | 1 | |||
| % времени недоступности АВР3 | 0,274% | 0,000% | 0,274% | |||
| Коэффициент зависимости АВР2 и АВР3 | 0 | 0 | ||||
| Суммарный % недоступности АВР2 и АВР3 | 0,001% | 0,001% | ||||
| Итоговый % времени недоступности схемы | 0,004% | 0,001% | 0,032% | 0,04% | 3,21 | 99,963% |
В данном примере весьма наглядно будет добавление резервного ДГУ. Эта добавка позволит нам легко приблизится к тем самым показателям, которые так часто указывают в своих проспектах сотрудники отдела продаж.
Хочется обратить внимание на тот факт, что сроки поставки запасных частей для ДГУ и трансформаторов мы не изменяли. Несложная задача по определению наиболее вероятного ЗИП и своевременное его приобретение и пополнение еще более улучшит показатели системы.
Финансовый анализ
Для самого простого подсчета давайте возьмем условные стоимости оборудования и рассчитаем количество капитальных вложений в каждый из вариантов.
| Стоимость оборудования | Стоимость | Доступность | |||||
| Трансформатор | ДГУ | АВР | проекта | сервиса | |||
| 1 000 000 | 500 000 | 100 000 | |||||
| Вариант 1 | 2 | 2 | 3 | 3 300 000 | 99,84% | ||
| Вариант 2 | 2 | 2 | 4 | 3 400 000 | 99,69% | ||
| Вариант 3 | 2 | 1 | 3+2 | 3 000 000 | 99,96% | ||
| Количество применяемого оборудования | |||||||
Что ж, цифры говорят сами за себя – выбрав третий вариант нам удастся не только увеличить доступность сервиса, но и сохранить бюджет проекта.
Заключение
Итак, в приведенных выше гипотетических примерах видно, что увеличение инвестиций в сложные проектные решения не всегда приводят к оптимальному результату. Гораздо важнее оказывается уметь анализировать не только технические, но и финансовые, логистические и операционные особенности проекта.
Отмечу, что подобный подход к проектированию все еще не распространен в мире. Кроме недостатка квалифицированных проектных команд причиной этого можно отметить и «разумную недобросовестность» как проектировщиков, так и поставщиков оборудования, которые более заинтересованы в максимизации своей вовлеченности в успешный проект, нежели в достижение скорейших сроков окупаемости и минимальных операционных затрат. В качестве простого решения этой проблемы можно рассматривать привлечение сторонних экспертов, услуги которых окупятся в дальнейшем в многократном размере. Хотя, конечно, самым правильным будет усиление компетенции своих сотрудников.
Автор статьи: Алексей Жумыкин
Сообщения, вопросы и ответы
Вы можете задать вопрос, написать комментарий, обсудить данную новость или статью.
Larrikin 04.08.2012 в 13:58
(подписан на сообщения)Есть такая проблема, что непонятно каких своих сотрудников компетенцию надо усиливать. Сетевиков? Нет, конечно. Системных администраторов? Нет, они тоже не годятся. Менеджеров IT отделов? Им не до этого. Нужен специальный человек. Что, правда? А какая это должность? Как его назвать? Нет ответа. Нет профессии. Нет должности.
Я их называю IT физиками, но меня никто не понимает. Есть получше варианты?
Алексей 10.08.2012 в 01:01
В контексте обсуждаемой темы — главный инженер. Для более серьезных проектов — Архитектор ЦОД. Если компания может себе это позволить, то несколько инженеров, отвечающих за различные подсистемы ЦОД. В любом случае нужет технический координатор. Его должность может варьироваться от специалиста по закупкам (если услуги ЦОД на аутсорсинге) до СТО. Задачи от этого не поменяются