Строим «облако». Часть вводная. Пояснения

Перед очередной тематической публикацией я хотел бы сначала ответить на вопросы, возникшие по поводу вводной части.

1. В этой серии публикаций я ни в коем случае не пытаюсь продать сервисы из своего или чужого «облака». Я пытаюсь рассказать о создании своего собственного «облака» — не важно, публичного или частного, так как принцип построения у них одинаковый. В доказательство тому и существуют гибридные «облака», причем все производители облачных решений включают функциональность гибридного «облака» — Cloud Bursting — в продукты для частных «облаков» даже самого низкого уровня, например, в HP CloudSystem Matrix или Cloupia. Логическая архитектура всех до единого «облаков» имеет следующий вид:

На верхнем уровне находятся портал самообслуживания пользователей с каталогом предоставляемых услуг и портал администратора, в котором последний подтверждает выдачу сервисов, управляет ими, мониторит ресурсы в пулах и доступность самих ресурсов. Это и есть единая консоль, из которой администратор может «провалиться» на инфраструктурный уровень и заглянуть отдельно в консоль ОС каждой системы (RDP, SSH, пр.), в management processor сервера (iLO, MP или HMC, пр.), консоль управления СХД (Command View, LUN Manager или Unisphere, пр.) и т.д. На уровне предоставления находится «технологическое ядро» любого «облака» — оркестратор. Именно в нем инфраструктура преображается в пулы ресурсов и осуществляется вся автоматизация рутинных задач и процессов. На этом уровне находятся и выполняются все скрипты и workflow. Уровень инфраструктуры включает в себя все ресурсы «облака» — серверы, ОС, ПО, СХД, ленточные библиотеки, LAN и SAN. ПО управления всеми этими системами в «облаке» называются «провайдерами ресурсов», потому что позволяют оркестратору на втором уровне предоставлять их в виде пулов.

2. Первая публикация была вводной, чтобы мы могли прийти к одному языку в обсуждении интересующих вопросов. Конкретика будет в следующих публикациях.

3. «Облако» — не панацея от всех проблем в ИТ. «Облако» не отменяет администраторов, но превращает их из системных в сервисных. Ведь «автоматизация» не означает полностью автоматическую работу системы без вмешательства человека, она применяется только для рутинных и повторяющихся задач. К примеру, конфигурация WWN и МАС адресов сервера, привязка к ним зон доступности и VLAN, установка ОС или приложений с middleware, обновлений драйверов и прошивок, патчинг ОС или приложений, создание и презентация LUN с СХД и т.п. в «облаке» происходят автоматически по команде администратора сервиса из своей единой консоли (консоли администратора). Подробнее об автоматизации я расскажу в следующих публикациях.

4. Институтом NIST (бывший ANSI) описаны самые популярные уровни сервисов — IaaS, PaaS и SaaS. Но они не единственные — многие Европейские ВУЗы, внедрившие «облако», для предоставления студентам лабораторных работ используют сервис уровня CaaS (Compute-as-a-Service), где каждому пользователю выдается небольшая инфраструктура с несколькими серверами, виртуальным коммутатором и дисками. Многие для реализации облачной модели владения сервисом и автоматизированного LifeCycle Management интегрировали свою инфраструктуру VDI в частное «облако» и получили сервис DaaS (Desktop-as-a-Service). В Швейцарии есть сервис-провайдер, который продает сервисы уровня DCaaS (DataCenter-as-a-Service), с помощью которого в «облако» по снятому «слепку» переносится полностью вся инфраструктура заказчика. Потому я придерживаюсь мнения, что в облаке должна быть возможность предоставления сервисов XaaS (Everything-as-a-Service).