Пора ли бизнесу строить свои дата-центры

В ночь на 8 октября атака беспилотника остановила дата-центр всем известный. Утром 9 октября пострадал второй ЦОД компании, в другом месте. Сроков восстановления нет.

Сервисы ЦОД используют сотни тысяч компаний. В эти дни многие из них поняли простую вещь. Их бизнес зависит от площадки, которой они не управляют и про которую почти ничего не знают.

Как на счет перейти на платформу для отказоустойчивой инфраструктуры ЦОД. После новостей хочется поднять вопросы на злобу дня.

Вопрос первый. Свой ЦОД или чужое облако

Публичное облако удобно. Ресурсы выдают за минуты, железо покупать не нужно, за площадку отвечает провайдер. Но провайдер отвечает за площадку по договору, а простой оплачивает ваш бизнес. Компенсация по SLA обычно ограничена стоимостью услуги за месяц. Выручку за неделю простоя она не покроет.

Свой ЦОД даёт три вещи.

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

Предсказуемость. Вы знаете, где лежат данные и кто к ним имеет доступ. Для госсектора, КИИ и банков это требование регулятора.

Стоимость на длинной дистанции. Аренда облака растёт вместе с нагрузкой. Собственное оборудование окупается за несколько лет при стабильном потреблении.

Есть и минусы. Нужны капитальные вложения, своя команда и время на запуск. Поэтому свой ЦОД оправдан, когда нагрузка стабильная, данные чувствительные, а простой стоит дорого. Для промышленности, энергетики, банков, госкомпаний и крупного ритейла это почти всегда так.

Важно другое. Свой ЦОД на одной площадке защищён не лучше облака. Он просто переносит риск к вам.

Раньше катастрофу для ЦОДа представляли так. Пожар, затопление, авария на подстанции. Это редкие события, и компании годами жили с одной серверной.

Теперь площадку могут уничтожить физически. Иногда вместе с соседними объектами в регионе. Резервная копия в соседней стойке погибнет вместе с основными данными.

Катастрофоустойчивая инфраструктура строится по трём принципам.

Две площадки работают как одна. Это называется растянутый кластер. Данные синхронно пишутся в оба ЦОДа. Если одна площадка падает, виртуальные машины перезапускаются на второй. Пользователи заметят короткую паузу, а не многодневный простой.

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

Единое управление. Когда у компании несколько ЦОДов, ими нужно управлять из одного окна. Иначе каждая площадка живёт своей жизнью, и переключение превращается в ручную операцию в стрессе.

Вендор имеет решение - Stretched Cluster объединяет две площадки симметричными парами узлов. Глобальная инфраструктура собирает несколько кластеров в одну федерацию с единым управлением.

Многие компании держатся за публичное облако из-за удобства. Разработчик сам создаёт виртуальную машину за пару минут и не пишет заявку в ИТ. В своём ЦОДе такой опыт обычно теряется, и заявка живёт неделю.

Решение называется частным облаком. Это облако внутри компании, на своём оборудовании и на своих площадках.

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

В итоге бизнес получает удобство публичного облака, а данные остаются в собственных ЦОДах компании.

ЦОД подверженный атакам восстановится. У него есть ресурсы и команда. Вопрос в другом. Что будет с вашей компанией, если завтра остановится ваша единственная площадка или площадка вашего провайдера?

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