Вы наверняка много раз видели эпические фотографии из ЦОД-ов, в которых за горизонт уходят стойки забитые серверами, установлены мощные генераторы и системы кондиционирования. Многие любят хвастаться такими кадрами, но меня всегда интересовало, а как операторы ЦОД-ов выбирают и настраивают своё оборудование? Почему, например, они устанавливают сервер «А», а не «Б», на что опираются – на скорость VM или потенциальное их количество в стойке, и как проектируют вычислительные мощности, особенно в современном мире гибридных облаков и искусственного интеллекта? Подробнее – эксперты «ИТ-ГРАД» в материале для HWP.
Что ставится во главу угла: скорость виртуалки или количество VM на стойку?
Скорость VM без какой-либо конкретики это абстрактное понятие, которое нельзя оценить без ввода критериев по которым она будет оцениваться. Например, типичные критерии оценки – это время отклика приложения, которое запущено на VM или время отклика дисковой подсистемы, на которой размещены данные виртуальной машины. Если заказчик хочет развернуть всеми нами любимый 1С на виртуальной машине, ему нужны гигагерцы по принципу «чем больше, тем лучше». Для таких задач выделяются кластера с высокочастотными процессорами с небольшим количеством ядер, так как многопоточность и производительность памяти и дисковой подсистемы не так важны для 1C, как например для нагруженной СУБД.
“Правильный” сервис-провайдер выделяет различные аппаратные платформы и дисковые ресурсы в отдельные кластера и пулы и размещает “типовые” виртуальные машины заказчиков в нужных пулах.
Предсказать на каком количестве виртуальных машин будет работать 1С, а где будут интенсивно использоваться дисковые ресурсы и надо планировать Флэш-СХД, заранее нельзя. Это приходит со временем, с получением определенной статистики в ходе эксплуатации облака, поэтому провайдеры, работающие на рынке долгое время ценятся выше, чем стартапы. У каждого провайдера своя платформа для развертывания VM, свой подход к планированию расширения и закупкам.
Мне видится грамотным подход к сайзингу исходя из определения “кубика” для вычислительного узла (compute node) и хранилища данных (storage node). В качестве вычислительных кубиков выбирается аппаратная платформа с определенным числом ядер CPU и заданным объёмом памяти. Исходя из особенностей платформы виртуализации делаются прикидки сколько “стандартных” VM можно запустить на одном “кубике”. Из таких “кубиков” набираются кластера/пулы где могут быть размещены VM с определенными требованиями к производительности.
Под “стандартной” виртуальной машиной понимается VM определенной конфигурации, например, 2 vCPU + 4 Гб RAM, 4 vCPU + 32 Gb RAM, а также учитывается резерв по ресурсам оперативной памяти на гипервизоре, например 25% и соотношение количества vCPU к суммарному числу ядер CPU в кубике (CPU over-provisioning). После достижения границы резерва в рамках пула начинается планирование закупки оборудования.
Подход к СХД
Что касается хранения данных, то кубик “storage node” выбирается исходя из показателей стоимости, ёмкости и IOPS на гигабайт – здесь всё стандартно. Оптимальным выбором в случае со storage-нодой является конфигурация когда использование максимально возможной емкости не приводит к потреблению процессорных ресурсов более чем на 80-85%. Другими словами, когда при максимально возможном использовании дисковых объемов узла мы можем получать с него проектные мощности по количеству IOPS с заданными показателями времени отклика (latency), прописанными в SLA.
Так же при подборе СХД учитывается еще ряд параметров (протокол доступа и сеть передачи данных, обвязка необходимая для коммутации вычислительных узлов и СХД, энергоэффективность и так далее, но я выделяю в качестве главного параметра – эффективность загрузки ресурсов
Сетевая инфраструктура
Тут все сильно зависит от платформы виртуализации. В случае с vmware хватает буквально двух-трех аппаратных серверов для развертывания полноценной SDN, в случае с Openstack может потребоваться вынос функционала SDN на выделенные аппаратные сервера для достижения требуемой производительности. Выбор аппаратных коммутаторов основывается на соотношении цены за порт. Есть ряд неплохих решений, которые кроме собственно портов представляют функционал SDN для платформ виртуализации (Сisco ACI, Arista, Mellanox).
Количество коммутаторов (и соответственно портов) определяется выбором аппаратной платформы. Если это стоечные сервера, то оптимально размещать TOR-коммутаторы (коммутаторы, устанавливаемые вверху серверной стойки, прим.ред) в каждую стойку и заводить их в ядро сети, а если выбрана конвергентная платформа высокой плотности (например Cisco UCS), необходимость в TOR-коммутаторах отсутствует.
Из всего выше сказанного ответ на вопрос “Что вы ставите во главу угла: скорость отдельной виртуалки или количество виртуальных машин на стойку?” очевиден: аппаратная часть облака должна быть спроектирована таким образом чтобы в один “кубик” вмещалось максимально возможное количество виртуальных машин, которе можно разместить без ущерба их производительности.
Экономия на лицензиях
Любой крупный сервис-провайдер, использующий проприетарное ПО, применяет схему лицензирования в виде денежных отчислений за определенные ресурсы, при этом экономия достигается при использовании большего числа этих ресурсов (поинтов).
Проблема энергопотребления
Что же касается энергопотребления – тут на мой взгляд проблема лежит немного в другой плоскости. Все коммерческие ЦОДы предоставляют в аренду “стандартную” стойку с подводом к ней 5-6 кВт электрической мощности. В ряде дата-центров это не является жестким ограничением, и заказчик может потреблять большую мощность, но в любом случае есть ограничения по превышению, например не более 3-х кВт. В ряде цод это жесткое ограничение, поэтому добиться 100% заполнения стойки скорее всего не получится. Казалось бы можно брать энергоэффективное оборудование, но, например высокочастотные процессоры и многосокетные аппаратные серверы потребляют немалую мощность, поэтому приходится идти на компромисс между мощностью «вычислительного узла” и возможностями размещения таких “кубиков” в одной стойке. 100% плотность размещения оборудования в стойке при его 75-80% загрузки по мощности на практике к сожалению не реализуема.
SLA (ответственность перед заказчиком)
В SLA должно быть прописано как минимум доступность услуги (управляющий интерфейс, сеть/доступ в интернет, доступность дисковых ресурсов). Значения этих параметров в среднем не превышают 99.9% по базовым компонентам (узлы СХД, локальная сеть, канал доступа в интернет), что допускает простой не более 43 минут в месяц.
Безусловно могут быть заключены более жёсткие соглашения SLA: отдельно можно прописывать детальные характеристики отдельного компонента услуги, например производительность дисковой подсистемы и её время отклика, ширину канала в интернет, резервирование канала и т.п. Такие расширенные условия, как правило, требуют выделенной инфраструктуры, но это частные случаи.
HWP: Что помогает предотвращать тормоза в виртуальной машине?
Николай Араловец | ИТ-ГРАД: Во-первых, механизмы автоматической балансировки нагрузки предоставляемые средой виртуализации, например VMware DRS и SDRS. Они позволяют динамически балансировать загрузку вычислительных узлов и ресурсов хранения данных. Во-вторых при проектировании закладывается некая граница потребления ресурсов в рамках пула/кластера, при достижении которой запускается процедура расширения (закупка аппаратных ресурсов и их ввод в эксплуатацию). В-третьих, мониторинг потребления ресурсов на уровне гипервизора.
Базовый принцип сайзинга заключается в том, что все серверы в рамках пула ресурсов – одинаковые по мощности, соответственно и стоимость их одинакова. Виртуальные машины не мигрируют за рамки кластера, по крайней мере, при штатной эксплуатации в автоматическом режиме.При смене платформы (например, при выборе новых процессоров) делаются необходимые замеры производительности в зависимости от частоты и количества ядер CPU, после чего оформляется спецификация на новый вычислительный узел, и новые пулы уже собираются из новых «кубиков».
HWP: Какие бенчмарки используются для подбора спецификации?
Николай Араловец | ИТ-ГРАД: В случае с узлом хранения данных мы пользуемся любым генератором нагрузки, можем также использовать бенчмарк от производителя платформ виртуализации. Вычисляем показатель утилизации СХД, соотношение IOPS на объем, понимаем что такая конфигурация нам подходит и начинаем её тиражировать. В случае с вычислительными узлами используем эмпирические методы, методики тестирования сайзинга и утилиты от производителей платформ виртуализации (https://wintelguy.com/vmcalc.pl. https://www.vmware.com/products/capacity-planner.html или https://access.redhat.com/articles/1337163) плюс собственный опыт.
Процессорная архитектура x86_64 в ближайшие 3-5 лет останется без изменения и будет преобладать на рынке облачных вычислений. ARM в их современной архитектуре – это точно не про облака, а скорее это ниша IoT, интегрированных решений и т.п. Несмотря на это, например, vmware поддерживает архитектуру ARM для своего гипервизора – это нишевое решение, которое может быть использовано для развертывания контейнеров на базе продуктов VMWare. На мой взгляд, Intel будет продолжать занимать львиную долю рынка, процессоров. С моей точки зрения, AMD вряд ли сможет потеснить Intel на рынке процессоров, и уж точно это не произойдет за счет возможностей безопасности, которые предоставляет платформа EPYC. Лично мне AMD всегда был симпатичен (домашняя платформа до сих пор работает на 4-х ядерном феноме:)), но скорее всего как и в середине нулевых «красным» банально не хватит ресурсов для борьбы с Intel-ом.
Будет ли рост скоростей сетевой инфраструктуры?
Скорости 10/40 GBps – это текущая реальность, в течении 3-5 лет в рамках внутренних облачных сетей, будет идти переход на 25/100 GBps, необходимости в более высоких скоростях во внутренних облачных сетях пока сложно представить. Максимум – это ядро большой сети, в рамках HCI платформ уже сейчас рекомендованы внутренние интерконнекты между нодами на скоростях 100 GBps для достижения максимальной производительности при операциях ввода/вывода. Активно будут продолжать развиваться облачные сетевые сервисы, микросегментация, CDN, и т .п. По моему мнению, должно сократиться количество проприетарного сетевого оборудования и сетевых операционных систем. Для получения большей гибкости будут использовать открытые платформы на базе стандартов Open Ethernet (https://ru.mellanox.com/open-ethernet/), хотя тут опять же встанет вопрос сетевой безопасности..
Как будут развиваться СХД?
В области систем хранения данных всё движется к окончательному переходу на Flash. Базовым протоколом для предоставления блочных устройств в операционную систему в течении 5-10 лет станет NVMe, в связи с этим начнется переход на протоколы передачи данных NVMe-oF-FC и более перспективный на мой взгляд NVMe-oF-Eth. С точки зрения отказа от дорогостоящих «традиционных» СХД от вендоров в рамках облаков мне видятся перспективным переход на распределенные файловые системы (например аналоги OneFS). С точки зрения архитектуры и модели продаж «традиционных» СХД мне нравятся решения от InfiniDat и Netapp, но это уже дело вкуса.
Тенденции в Cloud
Если брать общую тенденцию – будущее за теми провайдерами которые контролируют не только аппаратную составляющую облака, но и его софтверную платформу (гипервизоры, SDN, хранилища данных). Это модель гиперскейлеров (Amazon, Google, Alibaba). В России её пытаются повторить Яндекс и mail.ru. Общий облачный тренд – это «VM как код», «network как код», «storage как код». Публичные облака, построенные на проприетарных решениях оказываются достаточно дорогими, учитывая необходимость в отчислениях производителям ПО, но практика показывает что они востребованы (VMware vSphere как сервис успешно продается Amazon-ом). Почти все российские сервис-провайдеры используют продукты VMWare в качестве платформы виртуализации и для предоставления self-services.
Тенденции в Security
Как мне кажется, требования GDRP (фз-152) и PCI-DSS будут реализовываться в рамках выделенных сегментов облака. В рамках этих сегментов есть высокая вероятность что будут внедрятся, например, технологии аппаратного шифрования памяти и процессорных кэшей. Попытка распространения таких технологий на все публичное облако может привести к неоправданному усложнению его обслуживания, потери гибкости с точки зрения self-services и вводу ряда ограничений, что в свою очередь приведет к росту стоимости услуг провайдера. Если же технологии аппаратного шифрования данных в оперативной памяти быстро достигнут зрелости (будет поддержка как со стороны производителей аппаратных комплектующих, так и со стороны основных операционных систем) я не вижу проблем интегрировать их в публичное облако, но повторюсь, всё будет упираться в стоимость такой интеграции. На текущий момент 90% пользователей облака просто не нуждается в таких технологиях.
Напутственное слово
Не забывайте, что перед покупкой сервиса, заказчик может оценить критерии скорости, взяв VM на тест, чтобы проверить время пинга до датацентра где размещен сайт провайдера и его связанность с внешним миром, оценить производительность и время отклика дисковой подсистемы, на которой размещена VM, время выполнения запросов в рамках приложения, которое можно развернуть на тестовой виртуалке и так далее.
RSS
