Очень часто, говоря про блейд-серверы или про виртуализацию, я сталкиваюсь с тем что собеседники ошибочно воспринимают эти технологии как средство объединения ресурсов нескольких физических серверов в один большой. Тогда как на самом деле, блейд-серверы это всего лишь удобным образом упакованные в один корпус совершенно независимые машины. Виртуализация же серверов, в свою очередь, предназначена для консолидации нескольких задач (виртуальных машин) на одном физическом сервере:
А все дополнительные возможности (с красивыми названиями Live Migration, VMotion, DRS, HA и т.п.) служат для управления виртуальными машинами и их перемещением между серверами, но никак не для того, чтобы объединить ресурсы нескольких серверов для распределения между ними одной “тяжелой” задачи.
Хорошо, скажете Вы, а что делать, если стоит задача именно увеличить процессорную мощность системы по сравнению с имеющимся сервером? В большинстве случаев решением является приобретение сервера с большим числом процессоров. Но если задача реализована на x86 архитектуре и работала на двухпроцессорном сервере, то приобрести 4х процессорную машину можно без проблем. 8-ми процессорные системы тоже есть, но выбор гораздо меньше, а цена заметно выше. Ну а дальше? 32 процессора в одном сервере x86 уже фактически неразрешимая проблема – нужно переходить на другую архитектуру, что тоже не всегда возможно (да и требует более серьезных финансовых вложений). Для целого ряда задач решение есть – построение кластеров, где задача “распараллеливается” между серверами. Наиболее на слуху наверное Oracle Real Application Clusters (RAC) – несколько серверов объединяются для параллельной обработки запросов к СУБД, тем самым, увеличивается производительность системы. Другой, не менее часто встречающийся пример, – HPC (High-performance Computing), где вычислительная задача также разделяется на несколько подзадач, которые выполняются параллельно на нескольких вычислительных узлах. Оба эти примера объединяет одно – для работы требуется специальным образом оптимизированное приложение. В тех же случаях, когда такая оптимизация не была сделана, приложение работать либо вообще не будет (наиболее вероятный вариант), либо эффект от его запуска на кластере будет в лучшем случае нулевым. Кроме того, для успешной работы приложения необходимо приложить немало усилий к настройке самого кластера (например, в ряде случаев требуется наличие кластерной файловой системы, обеспечивающей параллельный доступ к данным с нескольких узлов).
Однако уже давно существуют способы объединить серверы через интерфейсы с низкой латентностью и высокой пропускной способностью (например Infiniband), а это, в свою очередь, открывает двери для протокола RMDA (Remote Direct Memory Access). RDMA позволяет приложению, исполняющемуся на одном сервере, получать доступ к оперативной памяти другого сервера, как если бы эта память была его собственная. Казалось бы, стоит сделать небольшой шаг и можно будет именно объединить ресурсы нескольких машин вместе, без необходимости в модернизации приложений и прочих сложностей, но до недавнего времени таких решений не было.
Но на днях мне попалась заметка со ссылкой сразу на двух производителей, которые “взяли быка за рога”: Scale MP и 3leaf Systems. Оба решения позволяют объединить несколько обычных серверов в один большой виртуальный SMP сервер, выполнение на котором приложений не требует их модификации для работы на кластере. Фактическая реализация очень похожа – для создания “объединительной” среды используется высокоскоростной интерфейс. 3leaf Systems используют свой собственный ASIC, который на текущий момент устанавливается в кастомизированные платы Supermicro для процессоров AMD, но в ближайшее время планируется решение и на процессорах Intel Xeon с поддержкой QPI. Dynamic Data Center Software позволяет выделять приложению ресурсы с гранулярностью на уровне отдельных узлов, либо на уровне процессорного ядра, а в скором времени обещают и динамическое выделение ресурсов без перезагрузки виртуальной машины. Уже сейчас можно использовать вместе до 16ти серверов (до 192 ядер) и суммарно до 1ТБ памяти.
Решение же от Scale MP может работать на самых разных системах, а для связи узлов друг с другом используется Infiniband. Серверы в рамках даже одного кластера могут отличаться друг от друга, наверное в т.ч. и из-за этого технология называется vSMP (v – versatile, универсальный).
Основной продукт – vSMP Foundation for SMP является наиболее "продвинутым” вариантам и позволяет объединить до 255 ядер и 4ТБ памяти в один SMP сервер, поддерживается деление общего процессорного пула между виртуальными машинами (одна VM должна включать минимум два узла), для небольших конфигураций можно обойтись и без Infiniband коммутатора – узлы можно соединять друг с другом напрямую. Более бюджетный вариант vSMP Foundation for Cluster отличается от “старшего” брата ограничением памяти в 512ГБ и использованием процессоров не старше 2.4ГГц. vSMP Foundation for Cloud позволяет динамически вводить машины в общий пул –загрузка производится по сети (а не с флэшки, как в остальных вариантах). Очень интересной возможностью является использование различных конфигураций в рамках одного кластера: для приложений, крайне требовательных к объему памяти, но не столь требовательных к числу процессорных ядер, можно строить систему, в которой часть узлов с быстрыми процессорами предназначена непосредственно для исполнения приложения, а другая часть – со сравнительно медленными процессорами, но большим объемом памяти, используется только для увеличения общей оперативной памяти, выделяемой приложению (процессоры этих узлов не будут использоваться для работы пользовательского ПО):
Конечно же, такое “объединение” ресурсов не является заменой failover кластеру – любая аппаратная проблема внутри такой системы приведет к полной остановке приложения и потребуется перезапуск системы. Возможность изоляции сбойного узла предотвращает длительный простой, но если требуется высокая доступность приложения, то помимо объединения ресурсов в “большой” SMP сервер, необходимо предусмотреть и такие способы резервирования как кластер высокой доступности.
С учетом того, что цены на Infiniband снижаются все сильнее и построение инфраструктуры уже практически эквивалентно стоимости FC SAN, описанные решения по построению больших SMP систем имеют довольно много шансов занять вполне заметную нишу. Причем, от чисто вычислительных задач интерес постепенно будет смещаться в сторону бизнес-приложений (СУБД и т.п.).
Читать дальше ...
Сообщения
