Архитектуры центров обработки данных общего назначения (такие ЦОДы сегодня все еще широко применяются) хорошо отрабатывали свои задачи в прошлом, но с недавних пор большинство из них достигли своих границ масштабируемости, производительности и эффективности. В архитектуре таких ЦОД обычно используется принцип совокупного выделения ресурсов — процессоров, жестких дисков и ширины сетевых каналов.
При этом изменение объема используемых ресурсов (увеличение или уменьшение) происходит в таких ЦОДах дискретно, с заранее определенными коэффициентами. Например, при коэффициенте 2 мы можем получить такой ряд конфигураций:
- 2CPU, 8 GB RAM, 40GB storage;
- 4CPU, 16GB RAM, 80GB storage;
- 8CPU, 32GB RAM, 160GB storage;
- …
Однако, для множества задач эти конфигурации оказывается экономически неэффективными, часто клиентам достаточно некоей промежуточной конфигурации, например, — 6CPU, 16GB RAM, 100GB storage. Таким образом, мы приходим к пониманию, что вышеуказанный универсальный подход к выделению ресурсов ЦОД оказывается неэффективным, в особенности при интенсивной работе с большими данными (например, быстрые данные, аналитика, искусственный интеллект, машинное обучение). Пользователи в таких случаях хотят иметь более гибкие возможности управления используемых ресурсов, им необходима возможность независимого друг от друга масштабирования используемых процессоров, памяти и хранилищ данных, сетевых каналов. Конечной целью этой идеи является создание гибкой компонентной инфраструктуры.
Рис. 1. Дата-центрированная архитектура ЦОД.
В ответ на подобные требования пришли гиперконвергентные инфраструктуры (HCI, Hyper-Converged Infrastructure) ЦОД, которые объединяют все вычислительные ресурсы, системы хранения данных и сетевые каналы в единую виртуализированную систему (рисунок 1). Однако и в этой структуре для расширения границ масштабируемости (добавления новых СХД, памяти или сетевых каналов) требуется установка дополнительных серверов. Это предопределило появления подхода, основанного на расширении инфраструктуры HCI фиксированными модулями (каждый из которых содержит процессоры, память и хранилище данных), что в итоге не дает того уровня гибкости и предсказуемой производительности, которая столь востребована в современных ЦОДах.
На смену HCI уже идут компонентно-дезагрегированные инфраструктуры (CDI, Composable-Disaggregated Infrastructures), которые разработаны с целью преодолеть ограничения конвергентных или гиперконвергентных ИТ-решений и обеспечивают лучшую гибкость для ЦОД.
Появление компонентно-дезагрегированной инфраструктуры.
Для преодоления проблем, связанных с архитектурой ЦОД общего назначения (фиксированное соотношение ресурсов, недоиспользование и избыточное резервирование), сперва была разработана конвергентная инфраструктура, состоящая из предварительно сконфигурированных аппаратных ресурсов в рамках единой системы. Вычислительные ресурсы, системы хранения и сетевого взаимодействия в них дискретны и объемы их потребления настраиваются программно. Затем конвергентные структуры трансформировались в гиперконвергентные (HCI), где все аппаратные ресурсы виртуализированны, а выделение необходимых объемов вычислительных ресурсов, хранилищ и сетевых каналов автоматизировано на программном уровне.
Несмотря на то, что HCI объединяют все ресурсы в единую виртуализированную систему, этот подход также имеет свои недостатки. Чтобы добавить клиенту, например, существенно больший объем СХД, оперативной памяти или расширить сетевой канал, в архитектуре HCI для этого потребуется использовать дополнительные процессорные модули, даже если они не будут использованы непосредственно для вычислительных операций. Как следствие, мы имеем ситуацию, когда при создании ЦОД, более гибких в сравнении с предыдущими архитектурами, по-прежнему используют негибкие строительные элементы.
Как показали опросы ИТ-пользователей средних и крупных корпоративных ЦОД, в реальное пользование в них выделяется примерно 50% от общей доступной емкости СХД, при этом приложениями используется только половина из выделяемого объема СХД, процессорное время ЦОД также используются примерно на 50%. Таким образом подход с использованием фиксированных структурных систем приводит к их недозагрузке и не дает нужной гибкости и предсказуемой производительности. Для решения данных проблем была создана дезагрегированная модель, которую легко компоновать из отдельных функциональных модулей, используя программные инструменты с открытым API.
Компонентно-дезагрегированная инфраструктура (CDI) представляет собой такую архитектуру центра обработки данных, в которой физические ресурсы — вычислительные мощности, СХД и сетевые каналы рассматриваются как услуги. Предоставление приложениям-пользователям всех необходимых ресурсов для выполнения их текущей нагрузки происходит в режиме реального времени, достигая таким образом оптимальной производительности в рамках ЦОДа.
Компонентно-дезагрегированная модель против гиперконвергенции
Виртуальные серверы в компонентно-дезагрегированной инфраструктуре (рис. 2) создаются путем компоновки ресурсов из независимых пулов вычислительных систем, хранилищ и сетевых устройств в отличие от HCI, где физические ресурсы привязаны к HCI-серверам. Таким образом, CDI-серверы могут быть созданы и переконфигурированы по мере необходимости в соответствии с требованиями конкретной рабочей нагрузки. Используя API-доступ к ПО виртуализации, приложение может запросить любые необходимые ресурсы, получая мгновенную реконфигурацию сервера в режиме реального времени, без вмешательства человека — реальный шаг к самоуправляемому ЦОД.
Рис. 2: Гиперконвергентная модель (HCI) и компонентно-дезагрегированная (CDI).
Важной частью архитектуры CDI является внутренний интерфейс связи, обеспечивающий отделение (дезагрегацию) устройств хранения данных конкретного сервера от его вычислительных мощностей и предоставление их в пользование другим приложениям. В качестве основного протокола здесь используется > NVMe™-over-Fabrics. Он обеспечивает наименьшие сквозные задержки передачи данных между приложениями и непосредственно устройствами хранения данных. В результате, это позволяет CDI предоставлять пользователям все преимущества СХД с прямым подключением (низкая задержка и высокая производительность), обеспечивая оперативность и гибкость за счет совместного использования ресурсов.
Рис. 3. Структура NVMe-over-Fabrics.
Сама по себе технология NVMe (Non-Volatile Memory Express™) — это оптимизированный высокопроизводительный интерфейс с низкой задержкой, использующий архитектуру и набор протоколов, разработанных специально для подключения дисков SSD в серверах через шину PCI Express. Для CDI данный стандарт был расширен до NVMe-over-Fabrics — за пределы локальных серверов.
Эта спецификация позволяет флэш-устройствам взаимодействовать по сети (используя разные сетевые протоколы и среды передачи – см. рис. 3), обеспечивая такую же высокую производительность и столь же низкую задержку передачи, что и локальные NVMe-устройства. При этом практически не существует ограничений на количество серверов, которые могут совместно использовать устройства NVMe-over-Fabrics или на количество таких устройств хранения данных, которые могут быть доступными одному серверу.
Потребности современных приложений с интенсивным использованием больших данных превышают возможности традиционных архитектур ЦОД, особенно в плане масштабируемости, производительности и эффективности. С появлением CDI (компонентно-дезагрегированная инфраструктура) архитекторы ЦОД, поставщики облачных услуг, системные интеграторы, разработчики ПО для СХД и OEM-производители могут предоставлять услуги хранения и вычисления с большей экономичностью, гибкостью, эффективностью и легкостью масштабирования, динамически обеспечивая требуемый SLA для всех рабочих нагрузок.
