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

===== Ограничения однооблачной архитектуры =====
Традиционная архитектура с одним облачным контуром (single cloud) обеспечивает централизованное управление, но имеет ряд слабых мест:

<WRAP important>
- **Ограниченная масштабируемость:** при увеличении числа узлов резко растут задержки и нагрузка на контроллеры.  
- **Единая точка отказа:** сбой в центральном облаке может привести к остановке всех сервисов.  
- **Зависимость от поставщика:** переход на другую платформу требует миграции данных и сервисов.  
- **Низкая гибкость при росте нагрузки:** расширение ресурсных пулов требует перестройки инфраструктуры.
</WRAP>

==== Типовая схема однооблачной среды ====
<WRAP box round>
**Архитектура с одним облачным контуром**
<mermaid>
flowchart LR
  classDef small font-size:17px,stroke-width:1px,padding:6px;

  User["Пользователи / клиенты"]:::small --> Service["Облачный интерфейс доступа"]:::small
  Admin["Администратор ЦОД"]:::small --> Service
  Service --> Manager["Менеджер облака (контроллер / панель)"]:::small
  Manager --> Pool["Пул ресурсов: вычисления / хранилища / сеть"]:::small
  Pool --> Node1["Узел 1"]:::small
  Pool --> Node2["Узел 2"]:::small
  Pool --> Node3["Узел 3"]:::small
</mermaid>
</WRAP>

<WRAP info>
На практике такие системы часто реализованы на базе OpenStack или VMware vSphere. В России аналогичные решения используют **Яндекс Облако**, **Selectel**, **VK Cloud** и корпоративные облака крупных предприятий.
</WRAP>

===== Узкие места однооблачных решений =====
- При масштабировании более 200 узлов резко увеличивается задержка отклика сервисов (до 10 с).  
- Централизованные контроллеры не справляются с синхронизацией кластеров при больших объёмах данных.  
- Перенос сервисов в другое облако требует ручной миграции и изменений в API.  
- Высокие риски потери доступности при аварии или техническом обслуживании главного центра.

<WRAP important>
Однооблачные инфраструктуры хорошо подходят для стабильных систем среднего масштаба, но становятся ограничением при росте нагрузки или при необходимости геораспределённости.
</WRAP>

===== Мультиоблачная архитектура =====
Мультиоблачная архитектура (multi-cloud) предполагает использование нескольких независимых облаков — как публичных, так и частных — объединённых общей логикой управления.  
Такая схема снижает риски отказов, повышает гибкость и позволяет выбрать оптимальную площадку по стоимости, географии или требованиям безопасности.

==== Типовая схема мультиоблачной среды ====
<WRAP box round>
**Архитектура с несколькими облачными площадками)**
<mermaid>
flowchart LR
  classDef small font-size:16px,stroke-width:1px;

  User["Пользователи / клиенты"]:::small --> UI["Единый интерфейс доступа"]:::small
  Admin["Администратор платформы"]:::small --> UI

  subgraph C1["Облако №1 (Яндекс Облако)"]
    M1["Менеджер облака"]:::small --> R1["Пул ресурсов\n(ЦОД Москва)"]:::small
  end
  style C1 fill:#fff9d9,stroke:#d4c882,stroke-width:1px;

  subgraph C2["Облако №2 (VK Cloud / Selectel)"]
    M2["Менеджер облака"]:::small --> R2["Пул ресурсов\n(ЦОД Санкт-Петербург)"]:::small
  end
  style C2 fill:#fff9d9,stroke:#d4c882,stroke-width:1px;

  subgraph C3["Облако №3 (корпоративное облако)"]
    M3["Менеджер облака"]:::small --> R3["Пул ресурсов\n(внутренний кластер)"]:::small
  end
  style C3 fill:#fff9d9,stroke:#d4c882,stroke-width:1px;

  UI --> M1
  UI --> M2
  UI --> M3
</mermaid>
</WRAP>


<WRAP info>
Такая модель позволяет использовать сильные стороны разных поставщиков:  
- **Яндекс Облако** — геораспределённые узлы и API, совместимые с AWS;  
- **VK Cloud** — высокая интеграция с российским интернет-сегментом и VK ID;  
- **Selectel** — развитые частные соединения между площадками;  
- **Корпоративные облака** — хранение конфиденциальных данных в периметре компании.
</WRAP>

===== Преимущества мультиоблачных решений =====
<WRAP info>
- Повышение отказоустойчивости за счёт дублирования сервисов.  
- Гибкость выбора поставщика под конкретные задачи.  
- Оптимизация стоимости за счёт комбинирования площадок.  
- Возможность геораспределённого хранения данных.  
- Снижение зависимости от одного вендора и API.
</WRAP>

===== Сложности и вызовы =====
<WRAP important>
- Разнородность интерфейсов и политик безопасности разных облаков.  
- Необходимость централизованного мониторинга и балансировки.  
- Различия в API и форматах виртуальных машин.  
- Увеличение требований к компетенции администраторов.  
- Более сложное управление затратами (billing и трафик между площадками).
</WRAP>

===== Типовые сценарии применения =====
- Резервное копирование между облаками (например, **Яндекс + VK Cloud**).  
- Разделение сервисов по зонам: публичные API — в внешнем облаке, внутренние БД — в корпоративном.  
- Обеспечение непрерывности бизнеса (BCP) с распределением узлов по регионам.  
- Вычислительные задачи и машинное обучение — на внешних ресурсах, хранение — внутри компании.

===== Ключевые идеи =====
<WRAP tip>
- Мультиоблачная среда обеспечивает надёжность и гибкость при масштабировании.  
- Главная цель — устранение зависимости от одного поставщика и минимизация простоев.  
- Требуется унификация API, единый мониторинг и система управления политиками безопасности.  
- Для России перспективно развитие межоблачных шлюзов и платформ интеграции (**Cloud Bridge**, **РосПлатформа**, **SberCloud Hybrid**).  
- Оптимальной считается модель, сочетающая публичные и корпоративные площадки под единым контуром управления.
</WRAP>