Мега-ЦОДы — пионеры инноваций


    По последним исследованиям компании 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 кВт.



    Проблемы мега-ЦОДов

    Вообще, в плане проблем подобные центры обработки данных похожи на своих «младших собратьев»: им так же надо обеспечивать возможности исполнения тяжелых приложений с максимальной скоростью, так же важно масштабирование и оптимизация расходов. Единственное исключение — в силу размера любая ошибка, проблема или неэффективность обходится заметно дороже.

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



    Уроки мега-ЦОДов

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

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

    Второй принцип состоит в том, что попытки поддерживать надежность даже на уровне «пять девяток» — для большого центра обработки данных это дорого, да и в целом нереально. Вместо этого надо проектировать инфраструктуру так, чтобы подсистемы могли подвергаться сбоям, но вся система в целом продолжала работать. Необходимые для этого программные и аппаратные решения уже доступны на рынке, но пока еще они не характерны в корпоративных системах.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 19

      +2
      если добавить в каждый сервер ненужный светодиод, то при наличии 200 000 серверов стоимость светодиодов составит порядка 10 000 долларов, и даже если эти светодиоды будут «бесплатными» — потребление электроэнергии вырастет где-то на 20 кВт.


      Цифры впечатляют. Подумать только — немного размышлений, и можно сократить стоимость на $10К, да и на энергии экономить!

      Однако вдумаемся: если кто-то построил ЦОД на 200 000 серверов, и их туда закупил, разместил, запитал, запустил — мне кажется, его задачи таковы, что даже 10 тысяч погоды ему не сделают. Более того, если это 10 тыс. нужны, чтобы облегчить поиск сбойного узла (скажем, горит зеленый светодиод — все хорошо, красный — сбой, не горит — «что-то не так»), то лучше их заплатить, чем в 200 000 серверов (и еще каком количестве другого оборудования) искать концы.

      Я, конечно, утрирую. Экономия всегда хорошо. Просто надо думать в относительных величинах, и понимать, сколько за сколько мы платим. С тем же успехом можно потребовать от производителя серверов не клеить эмблемы на их корпуса, чтобы пол ДЦ испытывал меньшую нагрузку в смысле веса — ведь даже если эмблема весит 5 граммов, на 200 000 серверов это составит целую тонну! :)
        +3
        так ведь написано про ненужный светодиод. разумеется, есть нужные и полезные LED-ы, поэтому все решения требуют тщательнейшего анализа — что реально нужно, а без чего можно обойтись.
          +1
          Мы с Вами об одном и пишем: надо точно понимать, что и за что мы тратим/платим/расходуем, и решать в каждом случае, стоят ли это затраты того :)

          Но ДЦ на 200 000 серверов — это серьезно, что ни говори!
            +1
            да, я просто удивлен открывшейся для меня сложностью задачи проектирования больших ДЦ, вот и делюсь ощущением :)
              +1
              «Не боги горшки обжигают»! :)

              Зато, когда читаешь рекомендации и стандарты на ДЦ применительно к ДЦ на 100 стоек, думаешь — «они маньяки, зачем столько всего?!» Когда понимаешь, что требования писались в первую очередь для таких вот серьезных ситуаций, начинаешь куда больше ценить и оценивать труд разработчиков — и стандартов, и ДЦ.
                0
                Проектирование чего-то большого всегда связано с новыми ощущениями :)

                Неважно — ЦОД это, или хайлоад веб-проект, или ещё что-то. Выход за рамки типовых решений всегда приносит массу нелинейностей и всегда доставляет.
          +1
          Эффект больших чисел в массовом производстве всегда впечатляет:
          «Ааааа, что стоило китайцам поставить на плату пару конденсаторов здесь и здесь и крепить корпус на два шурупа, а не на защелки».
          Стоило: экономия в 1 цент на миллион штук это уже $10,000.
            0
            Ну да, стоит китайским семьям завести второго ребенка… :)
              +1
              а с китайцами очень много интересных особенностей. например изготовление пресс-формы даже при маленьком изменении чего-то — это весьма ощутимая сумма денег обычно.
                0
                Ну дак и пресс форма не простая штука
                  0
                  ну да, естественно. но часто как раз «маленькое улучшение» требует новой пресс-формы и т.д.
                    0
                    «7 раз отмерь, 100 раз подумай, отмерь еще 7 раз и только тогда делай пресс-форму»
            • UFO just landed and posted this here
                0
                Мне кажется тут не про дублирование и избыточность, а как раз наоборот. Что обеспечить работоспособность всех подсистем одновременно дорого, но можно сделать систему в целом менее чуствительной к отказу какой-либо конкретной подсистемы.
                  0
                  Статья достаточно общая, согласен, и не затрагивает конкретных примеров ПО. Это связано с тем, что конкретные решения, как упоминалось в статье, являются проприетарными, то есть написанными специально для конкретной компании, будь то Google, Yandex или Facebook. В общем случае, инфраструктура датацентров состоит из нескольких видов типовых серверов с определенными параметрами. Напиммер, сервер хранения, сервер кэширования, сервер баз данных — самые распространенные, и.т.д. Далее в дело вступает софт. Если говорить о дублировании, то «средним» показателем по больнице является 2.5 копии объекта. То есть любой файл хранится в двух или трех копиях. На двух или трех разных серверах. Дороговизна такого хранения компенсируется «нулевой» стоимостью контроллера (используются HBA вместо RAID) и использованием дешевых дисков. Это также связано с производительностью. Чем больше копий, тем выше производительность системы по этому файлу. Некоторые системы реплицируют файл столько раз, сколько это необходимо, чтобы добиться оптимальной производительности. В других случаях высоковостребованный файл кладется на специальные Storage-сервера с SSD. Я понимаю, что приведенной информации мало, для того, чтобы детально разобраться в технологиях. Но это действительно передний край строительства информационных систем, и за общими словами идут конкретные реализации. Ищите статьи Google, Yandex, Facebook, Amazon по архитектуре их систем. Кроме этого, есть сложившееся деление на архитекторов железа (коим в какой-то степени является автор статьи), архитекторов системного ПО (тоже имею отношение) и архитекторов прикладного ПО (вот здесь я как раз не очень хороший специалист). Архитектуры же супер-датацентров в большей степени формируются исходя из требований, предъявляемых последними.
                  0
                  думаю это задел на вторую статью… :)
                  • UFO just landed and posted this here
                  0
                  Чрезвычайно интересно! С удовольствием почитал бы продолжение темы :)
                    0
                    Виртуализация используется редко

                    Разме Microsoft не первёл/переводит свою инфраструктуру в облака?

                    Only users with full accounts can post comments. Log in, please.