Как мы построили программно-определяемый дата-центр в ящике стола
Проснулся я однажды пораньше и подумал:, а чего бы не построить дата-центр? Свой собственный, на Intel NUC — мини-ПК, на которых крутится половина нашего центра технологий Intel.
Наш кабинет по пути из офисной столовой, и кто-то сболтнул, что я делаю. Поэтому начали заходить коллеги поржать. Заглядывали, спрашивали, где я прячу дата-центр, потом смеялись.
На третий день смех внезапно прекратился, и многие начали чесать голову. Потому что получился мобильный ЦОД для демонстраций и обучения, который можно принести к заказчику в чемодане. Или установить на танк.
Эпопея строителя дата-центра — ниже.
Задача
В общем, нам часто нужны целые дата-центры для обучения инженеров серверного ядра и прогонов нового софта. Серверное время стоит очень дорого, и поэтому обычно приходится учиться на кошках. В очередной раз заказывая окно, мы вдруг поняли, что прямо под ногами (буквально) у нас лежит куча Intel NUC. Их нам дал Интел для центра решений, который мы открыли в начале года. И они как раз подходили. Обычные консьюмерские компьютеры довольно плохо ведут себя под постоянной нагрузкой, требуют сложного охлаждения и т. п. У нюков внутри i7, они рассчитаны на 90-процентную загрузку в течение всего времени работы (месяцы и годы), есть очень даже продуманный теплоотвод. Я вспомнил, как Apple хотела сделать дата-центровые стойки, пихая четыре мак-мини в один rack unit, и решил:, а почему нет-то?
Всё, что мне надо для объединения машин в ЦОД, — это свитч и хороший оркестрирующий софт. А партнерские лицензии VMware для демонстрации есть всегда. И я взялся строить из них SDDC — программно-определяемый дата-центр, где вся мощность и все виртуальные машины могут быть как полезной нагрузкой, так и частями инфраструктуры.
Вот как он выглядит в эталонной архитектуре VMware:
Конечно, не обошлось без эксцессов: в определенный момент мой ЦОД развалила уборщица. Пришлось отстраиваться заново.
1. Гипервизоры
Полный стек программно-определяемого дата-центра начинается с гипервизоров, чтобы получать виртуальные машины на физических. Именно виртуальные машины будут квантами будущего программного дата-центра.
Взяли коммутатор 10-портовый гигабитный, 5 нюков. И с ноутбука подключались к коммутатору и машинам.
Подключились, начали ставить. Сам ESXi поставился легко. Но вот только VMware не предполагали, что он может быть установлен на такое адское железо, поэтому сетевая карта нюка выпала из поддерживаемого железа (если вообще там когда-то была). А в нашем дата-центре это критично. Потому что наши компьютеры — это прилепка к сетевухе, а не наоборот.
Мы нашли нужный драйве в старой версии дистрибутива, добавили в новый 6.5 Update 1. Установили еще раз — сеть появилась. По той же причине отсутствия драйвера так и не смогли запустить SD-ридер. Пришлось использовать внешние флешки для загрузки.
2. Управление
Базовая настройка закончилась. Развернули vCenter. Это управляющий софт, он обеспечивает объединение наших нюков в высокодоступный, динамически балансируемый кластер и позволяет управлять ресурсами. Поставили на одну из коробок, и пришла пора разворачивать гиперконвергентную инфраструктуру во всей красе.
3. Программно-определяемая система хранения данных (SDS)
На этой стадии у нас есть виртуальные машины на серверах виртуализации, но нет единой системы хранения. Надо объединить диски серверов или подключить внешние полки, плюс добиться того, чтобы при отключении любого из серверов данные не терялись. То есть развернуть программно-определяемую систему хранения данных. Потому что отдельная стойка с флеш-фабрикой за 20–50 миллионов явно в ящик стола не лезла.
Программно-определяемая система хранения данных в стеке VMware — это vSAN. Настроился он гладко в духе «next-next-next-done», даже правильно определил NVMe-диски под кэш (да, представьте себе, у нас были и они). Но тут возникли проблемы с конфигурацией коммутатора.
Мы сразу знали, что будем зажаты в один гигабит на свитче, а vSAN в рекомендуемой конфигурации их надо 10, а лучше 2 по 10 — он хочет очень быстро меняться данными внутри шины. vSAN нужен Jumbo Frame — большой MTU в 9000 байт, ведь чем крупнее фрейм передачи, тем меньше накладных расходов и он быстрее работает. Поначалу наш скромный 10-портовый гигабитный коммутатор упорно не хотел применять настройки MTU. Несколько чашек кофе спустя он таки покорился и даже приятно удивил производительностью — vSAN работал достаточно быстро, несмотря на один гигабитный интерфейс в бэкенде.
Далее vSAN надо минимум два диска на узле. На нюке как раз два. Конфигурация: USB-флешка для загрузки гипервизора, один SSD по SATA 3.0 (Intel SSD DC S3520 объемом 480 ГБ), второй М.2 — Intel SSD Pro 6000p объемом 128 ГБ, который стал кэшем в vSAN. Собрался легко.
Если до этого заглядывающие коллеги сердечно желали успеха и уходили со смешком, то теперь многим стало интересно. Приходили раз за разом, спрашивали про состояние пациента.
Передо мной лежал следующий уровень — SDN, то есть программно-определяемая сеть. Это когда те же серверы виртуализации (в нашем случае нюки) становятся компонентами сетевой инфраструктуры.
Где-то в этом районе мой ЦОД развалила уборщица: просто рубанула питание всего пучка и положила нюки на их место в центре решений Intel. Я очень беспокоился, поскольку решения SDS совсем не любят отключения всех узлов, да еще и с нагрузкой, но после включения все завелось нормально. Забегая вперед, скажу, что в самом конце еще раз так отметился уже коллега, которому нужна была розетка. Тоже все поднялось окей, уже с полным набором софта.
4. Программно-определяемая сеть (SDN)
Стал разворачивать NSX от VMware. Тут пошло проще, но не просто. Ещё немного поразбирали пакеты — были проблемы с проксированием в нашей сети (которая использовалась для доступа к нюкам).
Внезапно именно нюки идеально подходят как фаерволлы, маршрутизаторы и балансировщики. Раньше в офисах старые Пентиумы-2 для этого использовали — вторая жизнь старой машины.
SDWAN дал еще одну фишку — программное управление каналами. У нас в ЦОДе появился интернет! Решение позволит управлять модемным пулом так, чтобы репрезентовать серверам все входящие как один канал.
5. Мониторинг и отчеты
Теперь нужен мониторинг. А то что за ЦОД без мониторинга, правильно? Стали ставить vRealize Operations. Он тоже предназначен, хмм, для других задач и для другого железа, поэтому в базовой конфигурации сожрал себе половину ресурсов моего дата-центра. Убавили (это не рекомендуется в нормальных ситуациях). В итоге он собирает данные о том, насколько эффективно используется наш ЦОД, где и каким виртуалкам выдано больше ресурсов, чем необходимо (никаким), где что происходит. Он смотрит нагрузку на хостах, делает инвентаризацию и дает советы, где что поменять. Он же через сим-провайдер получает информацию от железа: вентиляторы, температура, состояние дисков, задержки записи и так далее. Перед выходом из строя оборудования умеет в фоновом режиме мигрировать сервисы и данные с умирающего сервера — эта штука называется Proactive HA. Справедливости ради последнее настроить не удалось — не тот уровень железа, это вам не сервера Dell или HP.
Надо сказать, что я начал оставлять ЦОД под нагрузкой на ночь. Нюки грелись, и поначалу меня это пугало — по несколько раз в день заходил, чтобы их потрогать. Дома меня бы точно такой обогреватель беспокоил. Но коллеги из Интела сказали, что все пучком (хе-хе!), и я продолжил опыты.
6. Анализ логов
Следующее звено — система анализа логов и всякой «умной аналитики» — vRealize Log Insight. Здесь добавить особенно нечего, продукт развернулся и сразу заработал, нужно было лишь в качестве syslog сервера для всех компонентов нашего программного ЦОДа.
7. Портал самообслуживания с гуем
Следующий этап — vRealize Automation. Про него надо сказать только то, что он опять захавал кучу ресурсов. Развернулся штатно, но нагрузил ЦОД из пяти нюков на 90%. Тоже порезали немного и развернули базовый портал на нем.
Все!
Итого — получилось. Это теперь обучающий стенд, источник непрекращающихся анекдотов («А где ЦОД? А в кармане!», «А чего бекап не поставил? А он 100% ресурсов ест!», «Когда грид считать будем?») и демо-юнит. С полустойкой к заказчику не поедешь, а с этим — запросто.
Напомню, нюки еще имеют неплохую встроенную виброзащиту (в отличие от нормальных серверов) и вообще очень добротно сделаны, поэтому дорогу переживут:
Бекап в конце я все же поставил нормально, кстати.
Для чего такое интересно? Ну, на практике на том же наборе софта (с парой замен на более дешевые лицензии) и другом железе можно уместить в полустойку приватный ЦОД. Это надо компаниям на 100 человек типа инвестфондов, которые не хотят делиться своими данными наружу, и это часто решается дорогими ПАКами. Либо стойкой прямо в офисе с шумоизоляторами, в которую напиханы сервера, коммутаторы и упс.
Ах да! А еще я заработал отличную ачивку «строитель ЦОДа». И выиграл пиво.
Для исследователей
Если кто-то захочет повторить наш опыт, ниже привожу конфигурацию нашего стенда, которая апробирована и точно работает.
5 штук мини-ПК Intel NUC Kit NUC7i7BNH, в каждый установлены следующие комплектующие:
- 2 модуля оперативной памяти Kingston HyperX Impact 16GB 2133MHz DDR4 CL13 SODIMM
- M.2 SSD 128 ГБ Intel SSD Pro 6000p Series под кэш
- SATA 3.0 SSD 480 ГБ Intel SSD DC S3520 Series под хранение
- USB-накопитель 32 ГБ SanDisk Ultra Fit для установки гипервизора
Ссылки
- Платформа управления SDDC VMware vCloud Suite. Suite включает в себя следующие компоненты: vSphere, vRealize Operations, vRealize Log Insight, vRealize Automation, vRealize Business for Cloud, SDS VMware vSAN.
- SDN VMware NSX
- Мини-ПК Intel NUC
- Про программно-определяемый дата-центр
- Моя почта SSkryl@croc.ru
