Будущее инфраструктур центров обработки данных
Архитектуры центров обработки данных общего назначения (такие ЦОДы сегодня все еще широко применяются) хорошо отрабатывали свои задачи в прошлом, но с недавних пор большинство из них достигли своих границ масштабируемости, производительности и эффективности. В архитектуре таких ЦОД обычно используется принцип совокупного выделения ресурсов — процессоров, жестких дисков и ширины сетевых каналов.
При этом изменение объема используемых ресурсов (увеличение или уменьшение) происходит в таких ЦОДах дискретно, с заранее определенными коэффициентами. Например, при коэффициенте 2 мы можем получить такой ряд конфигураций:
2CPU, 8 GB RAM, 40GB storage;
4CPU, 16GB RAM, 80GB storage;
8CPU, 32GB RAM, 160GB storage;
…
Однако, для множества задач эти конфигурации оказывается экономически неэффективными, часто клиентам достаточно некоей промежуточной конфигурации, например, — 6CPU, 16GB RAM, 100GB storage. Таким образом, мы приходим к пониманию, что вышеуказанный универсальный подход к выделению ресурсов ЦОД оказывается неэффективным, в особенности при интенсивной работе с большими данными (например, быстрые данные, аналитика, искусственный интеллект, машинное обучение). Пользователи в таких случаях хотят иметь более гибкие возможности управления используемых ресурсов, им необходима возможность независимого друг от друга масштабирования используемых процессоров, памяти и хранилищ данных, сетевых каналов. Конечной целью этой идеи является создание гибкой компонентной инфраструктуры.
Рис. 1. Дата-центрированная архитектура ЦОД.
Читать дальше →
При этом изменение объема используемых ресурсов (увеличение или уменьшение) происходит в таких ЦОДах дискретно, с заранее определенными коэффициентами. Например, при коэффициенте 2 мы можем получить такой ряд конфигураций:
2CPU, 8 GB RAM, 40GB storage;
4CPU, 16GB RAM, 80GB storage;
8CPU, 32GB RAM, 160GB storage;
…
Однако, для множества задач эти конфигурации оказывается экономически неэффективными, часто клиентам достаточно некоей промежуточной конфигурации, например, — 6CPU, 16GB RAM, 100GB storage. Таким образом, мы приходим к пониманию, что вышеуказанный универсальный подход к выделению ресурсов ЦОД оказывается неэффективным, в особенности при интенсивной работе с большими данными (например, быстрые данные, аналитика, искусственный интеллект, машинное обучение). Пользователи в таких случаях хотят иметь более гибкие возможности управления используемых ресурсов, им необходима возможность независимого друг от друга масштабирования используемых процессоров, памяти и хранилищ данных, сетевых каналов. Конечной целью этой идеи является создание гибкой компонентной инфраструктуры.
Рис. 1. Дата-центрированная архитектура ЦОД.
Читать дальше →
Источник: Хабрахабр
Похожие новости
- Что делать, если ваш слон думает, что он баг?
- Как не потерять свои контейнеры у себя в инфраструктуре?
- Киберугрозы в первом полугодии 2025 года: анализ векторов атак на облачные и гибридные инфраструктуры
- Лицо, голос и тело по-датски
- Все тонкости GPG подписей
- Половина работающих в найме россиян хотят уйти в собственный бизнес в ближайшие два года
- «Сделано в России»: цифровые экосистемы МАЕР получили сертификат РЭЦ
- Бренд как медиа: что меняется, когда компания становится источником смыслов
- Foreman в изоляции: как мы построили отказоустойчивую и безопасную систему для массового деплоя ОС
- Пароли не там, где вы их оставили. Как работает DOM Clickjacking