По последним исследованиям компании EMC, объем данных, сгенерированных в 2012 году составляет 2.8 зеттабайта (10^21 байт) а к 2020 году эта цифра дорастет до 40 зеттабайт, что превосходит предыдущие прогнозы на 14%. Можно смело констатировать, что мы уже столкнулись с «великим потопом данных» и одним из ответов на это является рост доли самых больших дата-центров, которые часто называют «мега-ЦОД» — их доля по разным оценкам составляет примерно 25% рынка современных серверов.
Так же, как, например, в гонках «Формула-1», инновации зарождаются именно там, где необходимы запредельные показатели, но уже вскоре многое из этих новшеств внедряется в обычных серийных автомобилях. Так же и мега-ЦОДы являются одними из главных центров инноваций в информационных технологиях. Многие компании используют примеры сверхбольших дата-центров в своих решениях для обработки «больших данных», частных облаках и вычислительных кластерах. Мега-ЦОДы являются полигонами, на которых обкатываются ультрасовременные решения по масштабированию, повышению эффективности и экономичности.
Чаще всего мегацентры обработки данных строят компании-гиганты, типа Apple, Google, Facebook (более интересный и редкий пример — китайские компании типа Tencent и Baidu), поэтому эти дата-центры не узкоспециализированные. Сервера этих дата-центров занимаются и хранением данных, и обслуживанием СУБД, и обеспечением web-серверов, и более специфичными для компаний задачами: поиск, анализ поисковых запросов, аналитика и так далее.
Масштабы таких ДЦ поражают — обычно они содержат от 200 000 до 1 000 000 серверов, в которых установлены до 10 миллионов накопителей. В зависимости от задач сервера могут содержать только загрузочные диски, незащищенные диски или же защищенные RAID-массивы для критичных данных. Зачастую для ускорения работы дисковых подсистем используются гибридные решения на основе flash-памяти, например, такие как LSI Nytro, о которых я уже писал в прошлой статье [ссылка].
Сервера обычно объединяются в кластеры, содержащие примерно от 200 до 2000 узлов. Такие кластеры проектируются так, чтоб можно было быстро отключить проблемный узел в случае сбоя и перераспределить нагрузку между оставшимися. Обычно это делается на программном уровне.
Поскольку в мега-ЦОД одно приложение зачастую работает на тысячах и сотнях тысяч узлов, скорость передачи информации между узлами становится очень критичной. Для преодоления этих проблем в больших дата-центрах используются технологии 10 GbE и 40 GbE. Так как сети мега-ЦОДов обычно статические (это тоже помогает снизить время обработки транзакций), часто используется программно-конфигурируемая сеть (SDN).
Виртуализация используется редко, в основном для упрощения внедрения и дублирования образов. Программное обеспечение, чаще всего open source, позволяет осуществлять более тонкую его доработку и настройку (мега-ЦОДы — это в общем-то штучные явления, создающиеся для конкретных целей конкретных компаний).
В таких дата-центрах невероятно остро стоит вопрос снижения эксплуатационных расходов путем отказа от всего лишнего (разумеется до определенного предела). Цель оптимизации — упразднить все, что не относится к основным задачам, даже если это «достается бесплатно», поскольку даже бесплатное изначально решение может привести к дальнейшим эксплуатационным расходам. Простой пример: если добавить в каждый сервер ненужный светодиод, то при наличии 200 000 серверов стоимость светодиодов составит порядка 10 000 долларов, и даже если эти светодиоды будут «бесплатными» — потребление электроэнергии вырастет где-то на 20 кВт.
Проблемы мега-ЦОДов
Вообще, в плане проблем подобные центры обработки данных похожи на своих «младших собратьев»: им так же надо обеспечивать возможности исполнения тяжелых приложений с максимальной скоростью, так же важно масштабирование и оптимизация расходов. Единственное исключение — в силу размера любая ошибка, проблема или неэффективность обходится заметно дороже.
Одной из таких проблем являются отказы дисков. Несмотря на низкую стоимость замены, массированные отказы являются серьезнейшей проблемой, вызывающей серьезные сбои в работе отдельных кластеров, а порой и всего ЦОДа. Архивные хранилища, которые обычно используют для решения этой проблемы, потребляют много электричества и других ресурсов, даже если информация на них используется нечасто. Особенно это заметно при росте объемов данных, которые порой исчисляются уже не петабайтами, а экзабайтами.
Уроки мега-ЦОДов
Как я уже писал выше, многие архитектурные решения сверхбольших дата-центов находят свое место среди ЦОДов поменьше, поскольку они позволяют добиваться невероятной эффективности в соотношении затраченных ресурсов и вычислительной мощности. Что же это за принципы?
Первый, и, пожалуй, основной — это необходимость сделать инфраструктуру как можно более однородной (гомогенной). Такую инфраструктуру намного проще поддерживать и масштабировать. Оптимизация расходов там, где это не критично позволяет высвободить средства, которые надо вкладывать в более совершенные архитектурные решения, например такие, что позволят производить обслуживание с минимальным вмешательством.
Второй принцип состоит в том, что попытки поддерживать надежность даже на уровне «пять девяток» — для большого центра обработки данных это дорого, да и в целом нереально. Вместо этого надо проектировать инфраструктуру так, чтобы подсистемы могли подвергаться сбоям, но вся система в целом продолжала работать. Необходимые для этого программные и аппаратные решения уже доступны на рынке, но пока еще они не характерны в корпоративных системах.
