Будущее инфраструктур центров обработки данных
Архитектуры центров обработки данных общего назначения (такие ЦОДы сегодня все еще широко применяются) хорошо отрабатывали свои задачи в прошлом, но с недавних пор большинство из них достигли своих границ масштабируемости, производительности и эффективности. В архитектуре таких ЦОД обычно используется принцип совокупного выделения ресурсов — процессоров, жестких дисков и ширины сетевых каналов.
При этом изменение объема используемых ресурсов (увеличение или уменьшение) происходит в таких ЦОДах дискретно, с заранее определенными коэффициентами. Например, при коэффициенте 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. Дата-центрированная архитектура ЦОД.
Читать дальше →
Источник: Хабрахабр
Похожие новости
- Путеводитель по Docker. От основ контейнеризации до создания собственного докера
- Чтение на выходные: «Искусство быть невидимым. Как сохранить приватность в эпоху Big Data» Кевина Митника
- Spark_news: Зумеры быстрее всех выгорают на работе
- CRM-Group: Как собрать дашборд с основными метриками бизнеса с помощью нейросетей
- Plan-c-consult 175474: Как ваш бизнес может заработать больше? Строим бизнес-модели, которые работают
- Как масштабировать объём трафика и количество целевых действий. Чеклист
- Spark_news: «ЯНДЕКС» объявляет финансовые результаты за I квартал 2024 года
- Spark_news: Спрос на менеджеров маркетплейсов в России вырос на 27%
- Уязвимости на GitHub: в библиотеке Ruby, которую скачали 250 000 раз, модулях для электронных замков и популярных играх
- Избавляемся от паролей