15.09.2013 13:19

1336 прочтений

Все, что вы знали об архитектуре ЦОД, меняется

zeynikovАлександр Зейников, региональный менеджер LSI в России.

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

Начнем с самого странного. Мега-ЦОД (все, что хранит огромные объемы данных из соцсетей и исследований) и степень их развития меняют  понятия об оптимизации бизнеса. Большинство специалистов в области ЦОД устраивают стойки в качестве единицы измерения покупки. Некоторые считают такой единицей контейнер для жестких дисков. Но для мега-ЦОД единица измерения покупки – это мощность ЦОД. Посмотрев на ситуацию под таким углом, можно утверждать, что мега-ЦОД могут изменять в угоду каким-либо показателям энергопитание, площадь, количество используемых металлических конструкций, пропускную способность сети, принципы того, как исполняется работа и для чего нужно оптимизировать приложения. То есть, проще говоря, мы теперь больше ценим общую эффективность и функциональность, а не эффективность отдельных элементов ЦОД. Когда я исследовал функционирование ЦОД в университете, я понял, что между двумя этими понятиями просто пропасть, и общая эффективность – это именно то, что нужно в ЦОД…

Мега-ЦОД покупают много оборудования (шесть самых крупных, вероятно, приобретают примерно 10% всего оборудования на рынке), то есть 1) Мега-ЦОД должны определить, что именно они внедряют самостоятельно 2) производители должны много работать для того, чтобы дать мега-ЦОД именно то, что они хотят.
Это означает, что в прошлом внедрение инноваций в большей степени стимулировалось со стороны OEM-производителей, но теперь их место заняли мега-ЦОД. И намного активнее, чем до этого. Каков общий оптимальный показатель для сред ЦОД? Это соотношение объемов обработанной нагрузки к стоимости. Причем общей нагрузки и общей стоимости. Потратить больше или даже намного больше на оптимизацию определенного компонента в ЦОД – это нормально, если это обеспечит более высокую продуктивность на потраченный доллар.

Вот поэтому три самых крупных потребителя флэш-технологий в серверах – это Facebook, Google и Apple, за ними расположились некоторые другие крупные игроки. Если вам что-либо нужно от этих ЦОД – они быстро предоставят это благодаря эффективной работе флэш-технологий. Настолько эффективной, что некоторые сервисы будут доступны бесплатно.

Мега-ЦОД начали публиковать расходы и открывать сведения о своих архитектурах (например, OpenCompute) и предоставлять открытое ПО (проект Hadoop и его производные). Чтобы проиллюстрировать эту тенденцию, Amazon, например, довольно точно оценил стоимость своих сервисов. И она невероятно низкая.
Корпоративные клиенты же успели оценить данные цифры. Очень хорошо оценить. Это стало причиной того, что многие клиенты буквально «взбунтовались» против старых способов работы ИТ – то есть, покупки оборудования и выставления счетов. OEM-производители и поставщики услуг обеспечивают экономию средств корпоративных клиентов, но не в такой степени. Они слишком долго развивали инновации вокруг использования оборудования одного и того же производителя, «замыкая» клиентов в проприетарных архитектурах, в то время как мега-ЦОД в большей степени концентрировались на повышении эффективности. Экономия средств в пересчете на единицу оборудования позволяет установить больше оборудования и обеспечить более качественные сервисы.

Этот бунт выражается в двух явлениях. Первое заметно в квартальных отчетах OEM-производителей и поставщиков услуг. Ходят слухи о том, что IBM собирается продать серию X Lenovo; что Dell подумывает о делистинге; что Oracle пытается найти новое направление для своего бизнеса; что HP исповедует «новый взгляд на ИТ»… Второе – тот факт, что корпорации стремятся подражать мега-ЦОД в самой высокой степени и внедряют архитектуры частных облаков. И, скорее всего, многие их этих архитектур будут работать на основе тех же открытых технологий  файловых систем, как и в мега-ЦОД.

Куда заведут их всех мега-ЦОД? Это длинный список изменений, которые уже происходят повсеместно.

  • Простые, «непритязательные» сервисы. Все, что нужно, без излишеств.
  • Эффективное распределение нагрузки в пересчете на стойки, сниженное количество металлических конструкций, более малый вес, реализация эффективного воздухообмена.
  • Упрощенное управление, единое для оборудования от всех вендоров.
  • Системы DAS с распределенными файловыми системами, например, HDFS.
  • Ускорение работы баз данных, чувствительных к задержкам, за счет использования флэш-технологий
  • Новые программные и аппаратные решения, например, кэширование.
  • Автономные простые в управлении и установке кластеры в масштабных объемах.
  • Дезагрегация серверов – создание пула ресурсов
  • Альтернативные архитектуры процессоров (кроме x86)
  • Возможность обратиться к памяти на основе технологий следующего поколения, например, PCM, STT, ReRam и, возможно, флэш

Но корпорации также оценивают и другие вещи. Например, большие массивы систем NAS. Мне нравится сама «объектная» идея хранилищ файловых систем, но сетевые соединения могут стать причиной серьезных ограничений. Трафик от хранилищ данных совмещен с трафиком самой сети, что создает определенные «узкие места», а также становится причиной эффекта «бутылочного горлышка» между NAS-хранилищами. Давайте признаем, что люди обычно оценивают количество портов 10GE на сервере и верхнем коммутаторе в серверной стойке. Типичная СХД на основе карты SAS теперь оснащена восемью портами 12G, а это пропускная способность на уровне 96G. А у серверов может быть десять портов 10G? Да, я тоже так не думаю.

Но все это не просто теория. Один банк с Уолл-Стрит утверждает, что смог сэкономить – просто не поверите! – до 70% расходов, пойдя по стопам мега-ЦОД. Они были просто в шоке. А я не был, потому что сначала это казалось абсурдом, это было просто невозможно. Тогда я отнесся к этому утверждению именно так. Я посмеялся. Но… системы становятся проще и дешевле. Просто нужно покупать и поставлять меньше оборудования, в то время как решения о  OEM-производителей были напичканы избыточными функциями, чтоб обеспечить «уникальность» и «выгоду». Более простые системы покупаются у более «дешевых» производителей. Таким образом, существенно снижаются издержки на техническое обеспечение и обслуживание (нужно обслуживать меньше единиц оборудования, и нет этих грабительских сервисных контрактов от OEM). И, что не менее важно, многие дорогие лицензии на ПО заменяются эквивалентами на базе открытого кода. Чистая экономия – 70%. Так что не стоит смеяться.

Дизагрегация: общий пул ресурсов

Но, возможно, самая важная тенденция – это то, что производители серверов называют «дизагрегацией», но специалисты по архитектуре ИТ-систем называют это явление «общим пулом ресурсов».

Во-первых, стремление к дизагрегации – это не просто «расчленение» сервера на составляющие с целью снизить стоимость отдельных компонентов. Нет. Вы все равно приобретаете стойку – почему бы не скомпоновать среду так, чтобы соединить похожее с похожим? Каждый компонент имеет собственный жизненный цикл. У ЦП он составляет 18 месяцев. У DRAM – несколько лет. У флэш-памяти, скорее всего, - три года. У жестких дисков – от пяти до семи. У сетевого оборудования – от пяти до десяти. У источников питания – вечно? Почему бы не заменять каждый компонент в соответствии с его естественным жизненным циклом? Почему не привести все решение в соответствии с требованиями технологий, которые оно объединяет? Жестким дискам нужны устойчивые к вибрациям металлические корпуса.

Процессорам нужно хорошее охлаждение. Флэш-накопителям нужно постоянно работать без простоя. DRAM – наоборот.

Во-вторых, принцип пула ресурсов позволяет действительно эффективно использовать имеющиеся ресурсы. Системы должны изолировать их друг от друга. Что произойдет, если системы используют физическую память на 100%? Они работают намного медленней. А если у базы данных не хватает места для хранения данных? Это вызывает синий экран смерти. А если у сети недостаточно пропускной способности? В результате серверы излишне укомплектованы для выполнения своих задач. Излишняя память DRAM, излишняя пропускная способность, излишнее количество флэш-накопителей, излишние вращения шпинделя жестких дисков… Если у вас 1000 узлов, вы просто выбрасываете на ветер терабайты оперативной памяти, терабайты флэш-памяти, терабайты в секунду пропускной способности – а все это еще и потребляет много энергии. Еще хуже, если вы недальновидны в своих планах и покупаете сервера с малым объемом накопителей или оперативной памяти – с ними особо не разгонишься. Так что представьте себе 10 000 или 100 000 узлов – и ужаснитесь.

Если все ресурсы 30 -100 серверов свести в единый пул, вы можете распределять их в соответствии с потребностями отдельных серверов. Что более важно – вы можете конфигурировать системы в соответствии с логикой, а не физическими свойствами. Это значит, что не нужно максимально точно разрабатывать и планировать тип конфигурации и количество устройств на будущее. У вас есть что-то вроде «полуфабикатов», которые вы размещаете в стойках и посредством программных скриптов объединяете в конфигурации – то есть, получаете эффективное распределение ресурсов, поменять которое можно всегда. Нужно хранилище побольше? Или поменьше? Более производительная флэш-память? Дополнительная пропускная способность сети? Просто сконфигурируйте на свой вкус.

И это очень важно.

Конечно, это готовит почву для распределения главной системной памяти в этом пуле – как только будут готовы соответствующие решения следующего поколения – скорее всего, в 2015 году.

Нельзя недооценить проблемы с эксплуатацией масштабных кластеров из разнородных платформ. Многие мега-ЦОД имеют до шести платформ. Если вы думаете, что они устанавливают новые версии до того, как прекратится поддержка старых – стоит знать, что зачастую одновременно работают три версии одной платформы. То есть, это в итоге дает 18 различных платформ – для каждой существует отдельная версия ПО. То есть, если вам нужно управлять от 200 000 до 400 000 серверов и осуществлять их поддержку без присутствия большого количества специалистов – это просто сумасшедший дом. Организация пула ресурсов значительно облегчает эксплуатацию.

Альтернативные архитектуры процессоров – это уже Intel x86. Было время, когда Intel только начинала в серверном бизнесе – тогда сцена принадлежала Power, MIP, Alpha, SPARC… (а до этого - мейнфреймам IBM и т.д.). Каждое изменение обосновывалось изменением в структуре расходов на сервера. Мейнфреймы были заменены многопроцессорной архитектурой RISC – а она, в свою очередь, открыла путь x86.

Но сегодня Oracle утверждает, что они отказываются от x86 в коммерческих серверах и переходят на SPARC. IBM продает бизнес по производству серверов на x86 и переключается на Power. И, конечно, можно ожидать множество системных чипов на архитектуре ARM – об этом уже говорят HP и Dell. Что нужно осознать – это тот факт, что все эти предложения имеют основой архитектуру платформы и общую производительность приложений, а не только процессора.

Другой взгляд

Позвольте привести вам переписку с Уэйном Нейшеном, моим другом. Я думаю, он хорошо подытожил тренды, притом достаточно трезво.

«Неужели тебе это не напоминает о давнем времени, когда на рынок приходили компании, которые делали сервера на основе дешевых настольных CPU на архитектуре x86? Чем отличается сегодняшняя ситуация? Снижением издержек и дизагрегацией? Нет, конечно, они важны, но далеко не новы. 

  • А что нового? Я думаю, это новая тенденция покупки мега-ЦОД и практичный подход клиентов к мега-ЦОД.
  • До этого практичный подход практиковали несколько производителей серверов, которые давали толчок инновациям. Но теперь инновации обеспечиваются покупателями крупных мега-ЦОД.

Новая архитектура CPU? Нет, раньше «новой» была x86. ARM обещает снижение издержек, как и раньше Intel.

  • Что нового? Возможное совместное развитие производства микросхем – что в этом такого?
  • ARM и ее лицензиаты должны придерживаться постоянства и единства, как и когда-то Intel.
  • Если у кого-то из пяти-шести производителей системных чипов на ARM не получится, то другие усилятся за их счет. Неужели это было не так в момент прихода Intel на  рынок?
  • ISA не играет такой уж большой роли, то есть Intel (если сделает правильный выбор) все равно может использовать это как свое преимущество – как и ARM.
  • Микросхемы Intel проигрывают (и, возможно, продолжат проигрывать). Но Intel такие поражения могут пойти на пользу, как это было в случае AS/400, S/360 или DEC.

Принцип дизагрегации позволяет мега-ЦОД обеспечить работу сервисов без излишеств, но постоянство работы сервисов определит лидера. Возможно, среди множества компаний возникнет новый Intel».

Вот так-то.

 

blog comments powered by Disqus