Потянув за кукольные струны в HPC

Уже более десяти лет системные администраторы центров обработки данных пытаются выяснить, как взять под контроль свою все более сложную инфраструктуру и управлять ими таким образом, чтобы они могли не отставать, адаптироваться и масштабироваться с учетом быстрых изменений, новая норма. Они не могут просто полагаться только на сценарии оболочки для запуска серверов. Сценарии оболочки не масштабируются, конечно же, недостаточно для решения системных конфигураций на десятках и сотнях тысяч серверов, которые можно найти в современных центрах обработки данных.

В последние годы рост DevOps был вызван программным обеспечением, которое позволило системным администраторам автоматизировать многие функции, связанные с управлением серверами, от конфигурации системы до установки программы. Ключевыми среди них являются приложения с открытым исходным кодом, такие как Puppet, Chef и Ansible, которые теперь являются частью Red Hat ( который скоро станет частью IBM ), у каждого из которых есть немного другая метафора для управления инфраструктурой, как в помещениях, так и теперь в общедоступных облаках и расширяющихся до краев. Как мы отмечали на The Next Platform , многие из этих приложений, которые существуют уже более десяти лет, теперь превращаются в платформы автоматизации конфигурации и развертывания ,

По сути, Puppet выпускается в двух версиях: с открытым исходным кодом Puppet и коммерческими предложениями от Puppet (компании), чей евангелист HPC Пол Андерсон отправился на недавнюю конференцию SC18 в Далласе, чтобы напомнить участникам, что Puppet - как с открытым исходным кодом, так и с коммерческой версией - может сыграть важную роль в HPC и в решении того, что он назвал «железным треугольником» требований современных администраторов HPC: высокая пропускная способность, сложные конфигурации и минимизация рисков.

«Ожидается, что вы, как администратор, будете поддерживать высокую производительность своей системы», - сказал Андерсон. «Работы должны выполняться. Моделирование должно закончиться. В то же время ваша задача - минимизировать риск. Без простоев, без сбоев. Кроме того, вам приходится иметь дело со сложностью конфигурации. Команды просят вас поддержать новые версии программного обеспечения, внешние вещи, такие как новые версии операционных систем, приходят новые главные исследователи и спрашивают о чем-то. Вы сотрудничаете с некоторыми новыми организациями, и они требуют, чтобы вы делали что-то немного по-другому. Так что каким-то образом вы должны сбалансировать все эти вещи, и это ваш классический вариант выбора. Итак, классический способ справиться с этим - сказать, что мы не собираемся иметь дело со сложностью конфигурации. Мы дадим вам высокую пропускную способность, и мы избежим этого риска, имея статический кластер со статическим стеком, и вы отрегулируете то, как вы работаете, в соответствии с нашим способом работы кластера, и если вы это сделаете, мы сможем дать вам то, что вы хотите.

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

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

рост DevOps а также облако и контейнеры , помогает решить проблемы в HPC, и Puppet играет ключевую роль, сказал Андерсон.

Компания Puppet существует с 2005 года и насчитывает более 500 сотрудников. Кроме того, более 40 000 организаций используют Puppet, согласно сайту Puppet, поэтому он приобрел популярность. Сайт HPC CERN Дом Большого адронного коллайдера использует технологию с открытым исходным кодом по крайней мере с 2013 года, отметил он. DevOps развивалась со времен 2010 года, когда на первый план выходили контроль версий (например, Git), инфраструктура в виде кода (Puppet) и инструменты конвейера IaC (Hudson, позже известный как Jenkins).

«Многие организации, которые были более сфокусированы на услугах - вроде компаний, рожденных в облаке, ваших Google, ваших Facebook, ваших амазонки Ваши Netflix - они смотрели на это и говорили: «Как мы можем использовать это, чтобы повысить ценность бизнеса быстрее?» », - сказал Андерсон. «Как мы можем учесть мнение клиентов и внедрить их в наши продукты, чтобы мы могли более эффективно конкурировать?» По сути, это было что-то вроде проникновения через культуру повсюду. Так почему кукольный? Почему Puppet хорошо подходит для HPC? »

Он сказал, что существует множество причин, по одной из которых, Puppet является декларативным языком желаемого состояния. Администратор указывает необходимую им конфигурацию и позволяет инфраструктуре выяснить, как ее получить. Речь идет о ресурсах, которые составляют желаемое состояние. Программное обеспечение вычисляет желаемую конфигурацию, может имитировать изменения до того, как они будут введены в действие и применены, и гарантирует, что развернутое требуемое состояние будет применено автоматически. Все это можно собрать в каталог.

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

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

Puppet может работать с самыми разнообразными аппаратными средами HPC: от вычислительных узлов с разной скоростью до различий в узлах хранения и использования Графические процессоры от Nvidia или драм или ПЛИС от Xilinx или Intel. Программное обеспечение управляется, будь то вычислительная гидродинамика (CFD), биоинформатика, анализ данных или машинное обучение.

«У вас есть разнообразные аппаратные средства?» - сказал он. «Некоторые из ваших систем на физических серверах, некоторые на виртуальных, возможно? Если да, то хотите ли вы установить соответствующие инструменты поставщика? Вы хотите установить правильные вещи для управления виртуальными машинами? Вы можете управлять BIOS, RAM, CPU. Вам нужно отключить тот факт, что карта находится в порте PCI три против четырех? Рассматривать вашу систему как проблему управления состоянием, а не как пошаговый список команд для запуска, может быть иначе ».

Андерсон сказал, что такие организации, как NASA, все чаще используют HPC по требованию, используя такие инструменты, как OpenStack, для создания, роста и сжатия виртуальных кластеров, и Puppet может помочь в управлении этими средами. В HPC есть «возможность делать что-либо в режиме главного списка, чтобы он лучше масштабировался. Старые версии Puppet не очень хорошо масштабируются. Это было круто в 2010 году. В наши дни у нас есть такие вещи, как каталоги кеша, цепочки инструментов, оркестровка HPC по требованию, эфемерные узлы и контейнеры ».