`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Александр Кулаковский

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

+1414
голосов

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

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).

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

+1414
голосов

Напечатать Отправить другу

Читайте также

О-о! Уже лучше!
Особенно интересуют приближенные к реальности примеры.
По пункту 3 я бы, всё же, был осторожнее. Тут надо очень скурпулёзно рисовать границы применимости, т.к. звучит многообещающе, а на практике столько всяких "если"...

По п.3 чтобы не было всяких "если" рождается пресловутый Vendor lock-in, если уж завязались на HP - то и не пробуйте использовать что-нибудь другое, тогда у вас всё будет хорошо и с прошивками, и железом, и саппортом. Шаг в сторону и всё начинает подпираться костылями и, как следствие рушиться. Стандарты у всех свои.

А по поводу реальных примеров - мы построили Private Cloud для собственных нужд используя System Center плюс железо HP. Получилось довольно сердито учитывая бюджет.
Учитывая специфику роботы компании (разработка ПО), имеем:

1. Полигон для тестовых VM (билды, обкатка релизов) - тут используется упрощённая конфигурация - железо не первой свежести, выборочный мониторинг, выборочный бекап (это ж не продакшн)

2. Продакшн и пред-продакшн. Это в первую очередь сервисы с разной степенью нагрузки, которые компания продаёт клиентам. Мониторятся через SCOM. Доступность обеспечивается при помощи своей AS-ки.
Критические сервисы, которые уже выросли из коротких штанишек мы конечно же выносим в паблик клауд, типа ажура, амазона или фаерхоста и настраиваем мониторинг. Так гораздо спокойнее для нас и клиенты нынче любят почаще слышать что их бизнес крутится в "мега-клауде" :)

3. Своя внутренняя инфраструктура.
Тут всё банально: AD, Exchange, SharePoint и т.д.
Можно отметить что наш инфраструктурный клауд является гибридным, т.е. частично вынесен в Windows Azure. Благодаря своей масштабируемости, Active Directory очень хорошо ложится в модель когда один контроллер на земле, а второй в облаке, между ними - VPN.

Управляется всё это при помощи SCVMM (сети, вланы и СХД), порталом для енд-юзеров является App Controller.
В день может создаваться несколько VM, в данный момент крутится порядка 100 VM, ещё около 20 стопнуты за ненадобностью и для экономии аппаратных ресурсов.
Учитывая что состав ИТ отдела 3 человека, польза сильно ощутима, раньше приходилось тратить время на развёртывание и конфигурацию VM достаточно много времени. Теперь достаточно создавать темплейты при выходе новых ОС, апдейтить существующие, ну и блоки питания с хардами менять конечно же, от этого никуда не денешься :).
System Center выбран потому что позволяет расти и масштабироваться с минимальными затратами.

Добрый вечер!

Не совсем согласен. Например, НР уже 5 лет пропагандирует multi-vendor support. Я, будучи техническим специалистом компании НР, не раз обслуживал оборудование Cisco или, например, Hitachi.

У НР оркестратор имеет более 5000 коннекторов к различным вендорам и VMWare, и IBM, и Oracle. Ему уже 15 лет, за жто время его достаточно "допилили".
Продукт Network Automation поддерживает работу со всеми известными мне производителями сетевого оборудования. Найдите его Supportability Matrix - там вендоров 100+.
Да и все остальные вендора приходят к этой Multi-Vendor поддежке.

По поводу стандартов: Сейчас наоборот все стандартизируют свои протоколы. Все СХД enterprise уровня работают по SMI-S, для сетей создали SDN, у серверов - WBEM, SNMP,IPMI. Сейчас уже все практически все оборудование имеет более-менее общую стандартизацию.

Найдите его Supportability Matrix - там вендоров 100+.
Да и все остальные вендора приходят к этой Multi-Vendor поддежке.

А knowledge base по этим "Multi-Vendor Support" содержит овер-мильён статей :) плавали, знаем.
Multi-Vendor Support - это костыли подпираемые костылями.

Раньше моментально Вас поддержал бы, сам наплавался вдоволь:)но...

за последние полтора года все вендора очень продвинулись в этом вопросе, потому и появились такие сообщества как OpenStack и девелоперы SDN.

А вот про "появились девелоперы" SDN - можно поподробнее с примерами? С OpenStack все уже понятно, даже тут было несколько правильных статей на эту тему. Любопытна нонешняя судьба SDN девелоперов.

SDN сейчас даже Cisco начали воспринимать в серьез, хотя это сильнейший удар по их проприетарным коммутаторам и софту(хотя отдать должное надо, дело свое знают).

Cisco выпустила уже прошивки для Nexus линейки с поддержкой SDN API, и готовит свой appliance, HP свой appliance презентовал уже на HP Discover.

НР SDN апплайнс уже доступен к заказу и даже, вроде, есть один в Украине. Как только у меня будет возможность поковырять его, обязательно расскажу свои впечатления в подробностях. Или можно будет связаться как-нибудь и провести совместные тесты.:)

Кстати, пример вспомнил. Правда - не мой собственный, приводили его на семинаре от одного из девелоперов SDN.

Французкий телеком, внедрил у себя SDN, но только для двух задач - конф-коллов через Microsoft Lync и удаленной поддержки сотрудников через Team Viewer.
Результат видел своими глазами: через VPN с подключением 2Мбита задержки упали в 9 раз - до 0,7-0,9 милисекунд. Слайд-шоу полностью исчезло и люди спокой вели видео конференцию.
Технические нюансы, к сожалению, не знаю:(

SDN - это следующее "облако", где тоже не все так радужно. У той же Cisco, если не изменяет память, три разных (как всегда, несовместимых SDN-подобных платформы), другие вендоры проталкивают свои SDN-платформы. И это при том, что все они - добропорядочные члены Open Networking Foundation.
Так что, я бы не был столь оптимистичен :-)

Как внедрение SDN смогло так сократить задержку - вообще непонятно. SDN работает на уровне control plane - ускорить пакеты он может только оптимизировав маршруты. Вероятно, до этого у них там совсем все плохо было...

SDN - это уже сама по себе платформа, вендоры проталкивают свои апплайнсы, а стандарт OpenFlow
Насколько мне известно, Cisco выпустила поддержку API, так как сам SDN - сильный удар по Cisco.

Позволю себе не согласиться. SDN не может быть "платформой" по определению. Это в большей степени софт и стандарты. А задача вендоров - обеспечить совместимость железа, которое становиться (в неком абстрактном будущем) абсолютно "тупым", с этим самым софтом и стандартами. Чего, я пока не наблюдаю, потому и поднял тему. То что на поверхности - каждый вендор, имеющий отношение к сетевому оборудованию, в попыхах строит какие-то решения дабы застолбить место. А что там в глубине - вот это интересно бы знать.

"Любопытна нонешняя судьба SDN девелоперов."

Oracle всех купит...

http://www.oracle.com/us/corporate/press/2098918

http://www.oracle.com/us/corporate/press/1721421

Добрый вечер!

В первую очередь хотел сказать, что построили все действительно сурово, с умом и работоспособно. Молодцы:)

Есть пара вопросов:

1.Как App Controller себя зарекомендовал? Просто интересен фидбек, от правильных людей, которые с ним работают:)

2. Облако только на ВМы? Или физические сервера тоже деплоите? Если да, то чем?

3. Чарджбек ведете?

Спасибо.

1. App Controller минималистичен, прост (даже примитивен), не требует вообще никакого к себе внимания, там всё понятно и просто. Ни разу ни у кого из пользователей (даже с низкой квалификацией) не возникало вопросов при его использовании. Но при этом обладает всем необходимым для "заказа" и конфигурации VM. Тут всё зависит от администратора, если нормально созданы и описаны темплейты, наполнена библиотека - пользователю всё понятно.

2. Тут действует принцип разумной достаточности. Не так часто добавляются физические хосты. Надо будет - сделаем, System Center это всё умеет из коробки, WDS есть, а больше ничего и не нужно. А в облаке кроме ВМ есть ещё и понятие готовых сервисов (грубо говоря нескольких ВМ с описанными сетями, балансерами и т.д.), например часто требуется тестовая среда AD + SharePoint + Exchange - вот оно и создаётся в виде сервис-темплейта через App Controller и подаётся пользователю на блюдечке в готовом виде.

3. Мы клиентам не продаём вычислительные ресурсы, мы продаём сервисы. Поэтому считать ядра и гигабайты памяти нет особой необходимости хотя такой функционал есть. Да и затраты аппаратных ресурсов в общей картине настолько незначительны что их можно просто игнорировать, хотя в последнее время всё чаще ведутся разговоры про то чтобы кого-нибудь "захостить" по-взрослому. Честно говоря, экономия на з/п DevOps-ов даёт гораздо больший эффект. Мы небольшая компания, и нашему клауду ещё год не исполнился на самом деле.

Понятно, спасибо за ответ!

1. В общем, мне App Controller по своей простоте и примитивности мне напомнил Cloupia. Имплементация в два клика, работает просто примитивно и свои задачи выполняет.

2. Ну про сервисы это ясно, я ж об этом и пытался донести в первой публикации и разьяснить в этой:) А App Controller уже умеет делать темплейты мульти-тайр сервисов? раньше не умел.

3. Ну хотя бы для своего учета, я бы Вам посоветовал вести чарджбек. Как минимум, считать ТСО проданных сервисов, которое состоит и из вычислительных ресурсов тоже. А там и счета клиентам легче выставлять будет:)

А как называется Ваше "Облако" и компания?

www.n-ix.com
Облако никак не называется, потому оно и частное, а не публичное, мы его не продаём. Это наша корова и мы её доим :)

Two Tier Application и Three Tier Application точно есть, и элементарно рисуются в дизайнере (в стиле Visio) из существующих VM Templates, но не в App Controller а в SCVMM. Сам по себе App Controller ничего такого не умеет и предназначение у него - быть дружественной мордой для человека.

Я потому и удивился, что App Controller начал и такое делать!

Спасибо за инфу.

Круто! Реально круто. Вдруг чего, модно с глупыми вопросами поприставать, при случае, будет?

Спасибо.
На вопросы, если смогу, с радостью отвечу. Только я свои контактные данные на публичных ресурсах не оставляю.

Да я и тут могу спросить, я не гордый :) Вопрос все же больше гипотетический, но в букмарки добавил.

Спасибо!

Спасибо!

По поводу пункта 3: я с Вами абсолютно согласен. Именно в целях прорисовки применимости, перед каждым проектом внедрения "Облачной" инфраструктуры, я совместно с Заказчиками заполняю не один Planning Sheet и PreInstallation guid'ы, в которых очень подробно описаны границы и рамки применимости, вплоть до физических портов, номеров LUN'ов, МАС и WWN-адресов, серийников серверов, сборок ОС и т.д.

По поводу "если" - и тут Вы правы. Этих "если" достаточное кол-во, и то пока что. Главное знать все эти "если", и учитывать их на стадии планирования, тогда можно смело строить решение:)

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

Для частных облаков в большинстве случаев подходит модель "unitenant", т.к. в рамках одной организации достаточно одного набора системных политик, конфигурации пространств адресов, имен, L2-доменов и т.п. В облаках коллективного использования (по крайней мере, с развитой функциональностью) необходимо поддерживать множество таких наборов, причем часть пространств может пересекаться (например, несколько организаций могут одновременно использовать сеть 10/8 для внутренней адресации).

По этой причине облака коллективного использования чаще относятся к классу "multitetnant", а их архитектура включает дополнительный уровень абстракции, который и обеспечивает "tenant isolation".

Геннадий, добрый вечер!

Я с Вами соглашусь частнично.
Я писал о идентичности с технологической точки зрения. Сегодня все Частные Облака умеют работать, как multi-tenant решения, так и unitenant, и в этом плане они технологически также не отличаются, а вот с точки зрения эксплуатации - да! Коллективные реализовывают только как multi-tenant, за исключением очень частных случаев.
И, кстати, многие этим пользуются! Например, одна политика и пулы для тестеров и девелоперов, другая - для ДБА, третья - для BCS.

Дополнительный уровень tenant isolation все Вендора уже реализовали прямо в порталах даже начального уровня, таких как и Cloupia, Matrix Operating Environment, App Controller и т.д.

Что касается портала самообслуживания, то в нем я бы выделил два основных функциональных блока:

1) Subscription portal - подписка и управление объемом потребляемых ресурсов/услуг.
2) Operation portal - системное администрирование клиентского ландшафта (включая управление сетевой топологией и networkless доступ к серверным консолям).

В зависимости от типа облачных услуг центр тяжести может смещаться между этими блоками. Например, для простейших услуг типа VDS/VPS доминирует Subscription portal, т.к. администрировать, собственно, практически нечего. С другой стороны, для услуги "виртуальное частное облако" (выдача клиенту ресурсных пулов в полное распоряжение) основным блоком становится Operation portal, т.к. именно в нем клиент создает и управляет своим ландшафтом.

Согласен, но, по моему, это уже относится к кастомизации портала в конкретном проекте.

Добавлю свои 5 копеек о разнице частного и публичного облаков.
Ведь о том, какое это облако, можно судить по тому, с какой стороны фаервола он находится...
Ведь пользователь запрашивая сервисы не вникает в то, как они устроены, ему главное, что бы они работали...

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT