[Виртуализация, Облачные вычисления, Серверное администрирование] Очередной взгляд на облака. Что такое частное облако?

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 2 месяца
Сообщений: 27286

news_bot ^® написал(а)
05-Авг-2020 13:33

Цитировать

Рост вычислительных мощностей и развитие технологий виртуализации платформы x86 с одной стороны, и распространение ИТ-аутсорсинга с другой стороны привели к концепции utility computing (ИТ как коммунальная услуга). Почему бы не платить за ИТ так же, как за воду или электричество – ровно столько и ровно тогда, когда это нужно, и не более.
В этот момент и появилась концепция облачных вычислений – потребление ИТ услуг из «облака», т.е. из некоего внешнего пула ресурсов, не заботясь о том, как и откуда берутся эти ресурсы. Так же, как мы не заботимся об инфраструктуре насосных станций водоканала. К этому моменту была проработана и другая сторона концепции – а именно понятие ИТ-услуг и как ими управлять в рамках ITIL / ITSM.
Был разработан целый ряд определений облаков (облачных вычислений), но при этом не следует относиться к ним как к истине в последней инстанции – это лишь способ формализовать способы предоставления utility computing.

«Облачные вычисления – это технология распределенной обработки данных, в которой компьютерные ресурсы и мощности предоставляются пользователю как Интернет-сервис» Википедия
«Облачные вычисления представляют собой модель для обеспечения удобного сетевого доступа к общему пулу настраиваемых вычислительных ресурсов (например, сетей, серверов, систем хранения данных, приложений и услуг) по требованию, которые можно быстро выделить и предоставить с минимальными управленческими усилиями или минимальным вмешательством со стороны поставщика услуг» NIST
«Облачные вычисления – это парадигма обеспечения сетевого доступа к масштабируемому и гибкому пулу распределяемых физических или виртуальных ресурсов, предоставляемых в режиме самообслуживания и администрируемых по требованию» ISO/IEC 17788:2014. Information technology — Cloud computing — Overview and vocabulary.

Согласно NIST существует три основных типа облаков:
IaaS – Infrastructure as a Service — Инфраструктура как сервис
PaaS – Platform as a Service — Платформа как сервис
SaaS — Software as a Service Программное обеспечение как сервис

Для совсем упрощенного понимания разницы давайте рассмотрим модель Pizza-as-a-Service:

NIST определяет следующие необходимые черты ИТ услуги, позволяющие считаться облачной.

Универсальный сетевой доступ (broad network access) – услуга должна иметь универсальный сетевой интерфейс, дающий возможность подключения и использования услуги практически кому угодно с минимальными требованиями. Пример – чтобы использовать электрическую сеть 220В достаточно подключиться к любой розетке со стандартным универсальным интерфейсом (вилка), который не меняется от того, чайник это будет, пылесос или ноутбук.
Измеримость сервиса (measured service) – ключевой характеристикой облачной услуги является измеримость сервиса. Возвращаясь к аналогии с электричеством – вы оплатите ровно столько, сколько потребили с минимальной гранулярностью, вплоть до затрат на один раз вскипятить чайник, если за весь месяц вы были в доме один раз и выпили чашку чая.
Самостоятельное конфигурирование сервисов по требованию (on demand self service) – облачный провайдер предоставляет заказчику возможность разумного конфигурирования сервиса, без необходимости взаимодействия с сотрудниками провайдера. Для того, чтобы вскипятить чайник совершенно необязательно заранее связываться с Энергосбытом и заранее их предупреждать и получать разрешение. С момента как дом подключен (заключен договор) все потребители могут самостоятельно распоряжаться предоставленной мощностью.
Мгновеннная эластичность (rapid elasticity) – облачный провайдер предоставляет ресурсы с возможностью мгновенного наращивания / снижения мощности (в определенных разумных рамках). Как только чайник включен – провайдер немедленно выдает в сеть 3 кВт мощности, и как только выключен – снижает выдачу до нуля.
Объединение ресурсов в пул (resource pooling) – внутренние механизмы провайдера услуг позволяют объединять отдельные генерирующие мощности в общий пул (бассейн) ресурсов с дальнейшим предоставлением ресурсов как услуги различным потребителям. Включая чайник, нас менее всего волнует с какой конкретно электростанции поступает мощность. И все остальные потребители потребляют эту мощность вместе с нами.

Важно понимать, что описанные выше характеристики облака взяты не с потолка, а являются логическим выводом из концепции utility computing. И публичная услуга должна обладать этими характеристиками в рамках концепции. При несоответствии той или иной характеристике услуга не становится хуже и не становится «ядовитой», она всего лишь перестает быть облачной. Ну а кто сказал, что все услуги должны?
Почему я об этом отдельно говорю? За прошедшие 10 лет с момента появления определения NIST было много споров об «настоящей облачности» согласно определения. В США до сих пор иногда применяется в судебной сфере формулировка «соответствует букве закона, но не духу» — и в случае с облачными вычислениями главное именно дух, ресурсы в аренду в два клика мышью.
Необходимо отметить, что вышеперечисленные 5 характеристик применимы к публичному облаку, но при переходе к частному большинство из них становятся опциональными.

Универсальный сетевой доступ (broad network access) – в рамках частного облака организация полностью контролирует как генерирующие мощности, так и клиентов-потребителей. Таким образом, данную характеристику можно считать автоматически выполняемой.
Измеримость сервиса (measured service) – это ключевая характеристика концепции utility computing, оплата по факту потребления. Но как же оплачивать организации самой себе? В данном случае идет деление генерации и потребления внутри компании, ИТ становится провайдером, а бизнес-подразделения потребителями услуг. И взаиморасчет происходит между подразделениями. Возможно два режима работы: chargeback (при реальных взаиморасчетах и движении финансов) и showback (в виде отчетности в потреблении ресурсов в руб, но без движения финансов).
Самостоятельное конфигурирование сервисов по требованию (on demand self service) – внутри организации может быть общая ИТ служба, и в этом случае характеристика теряет смысл. Однако при наличии собственных ИТ-специалистов или администраторов приложений в бизнес-подразделениях необходимо организовывать портал самообслуживания. Вывод – характеристика опциональна и зависит от структуры бизнеса.
Мгновеннная эластичность (rapid elasticity) – в рамках организации теряет смысл ввиду фиксированности набора оборудования для организации частного облака. Может ограниченно применяться в рамках внутренних взаиморасчетов. Вывод – для частного облака неприменимо.
Объединение ресурсов в пул (resource pooling) – на сегодня уже практически не существует организаций, не применяющих серверную виртуализацию. Соответственно можно считать данную характеристику автоматически выполняемой.

Вопрос: Так что же такое все таки это ваше частное облако? Что компании нужно купить и внедрить, чтобы его построить?
Ответ: частное облако – это переход к новой административной модели взаимодействия ИТ-Бизнес, который на 80% состоит из административных мер и только на 20 из технологий.
Оплата только за потребленные ресурсы и легкий вход, без необходимости закопать несколько сотен миллионов нефти в капитальных затратах, обусловили новый технологический ландшафт и появление компаний-миллиардеров. Например современные гиганты Dropbox и Instagram появились как стартапы на AWS с нулевой собственной инфраструктурой.
Необходимо отдельно подчеркнуть, что инструменты управления облачными услугами становятся значительно более опосредованными, а ключевой обязанностью ИТ директора становится подбор поставщиков и контроль качества. Давайте рассмотрим проблематику этих двух новых обязанностей.
Появившись как альтернатива классической тяжелой инфраструктуре с собственными ЦОДами и железом, облака обманчиво легки. В облако легко войти, но вот вопрос выхода обычно обходится стороной. Как и в любой другой отрасли облачные провайдеры стремятся к защите бизнеса и усложнении конкуренции. Единственный серьезный конкурентный момент возникает лишь при первичном выборе поставщика облачных услуг, а далее поставщик приложит максимум усилий, чтобы заказчик от него не ушел. Причем далеко не все усилия будут направлены на качество услуг или их ассортимент. Прежде всего, это поставка уникальных услуг и использование нестандартного системного ПО, затрудняющего переход к другому провайдеру. Соответственно, при выборе поставщика услуг необходимо одновременно формировать план перехода от этого поставщика (по сути полноценный DRP – disaster recovery plan) и продумывать архитектуру хранения данных и резервных копий.
Второй важный аспект новых обязанностей ИТ директора – контроль качества услуг от поставщика. Практически все облачные провайдеры соблюдают SLA по собственным внутренним метрикам, что можем иметь крайне опосредованное значение к бизнес-процессам заказчика. И соответственно внедрение собственной системы мониторинга и контроля становится одним из ключевых проектов при переносе значимых ИТ систем к облачному провайдеру. Продолжая тему SLA необходимо подчеркнуть, что абсолютное большинство облачных провайдеров ограничивают ответственность за неисполнение SLA в месячный абонентский платеж или в долю от платежа. Например, AWS и Azure при превышении порога в доступности в 95% (36 часов в месяц) сделают 100% скидки к абонентской плате, а Яндекс.Облако – 30%.

https://yandex.ru/legal/cloud_sla_compute/
Ну и конечно же, не надо забывать, что облака бывают не только в исполнении мастодонтов класса Amazon и слонов класса Яндекса. Облака бывают и поменьше — размером с кошку, или даже мышь. Как показал пример CloudMouse, иногда облако просто берет и заканчивается. Вы не получите ни компенсации, ни скидки — вы не получите ничего, кроме тотальной потери данных.
Ввиду указанных выше проблем с реализацией ИТ систем высокого класса бизнес критичности в облачных инфраструктурах в последние годы наблюдается явление «облачной репатриации».

К 2020 году для облачных вычислений пройден пик раздутых ожиданий и концепция находится на пути к канаве разочарований (согласно хайп циклу Гартнер). Согласно исследованиям IDC и 451 Research до 80% корпоративных заказчиков возвращают и планируют возвращать нагрузки из облаков в собственные ЦОДы по причинам:

Повысить доступность / производительность;
Сократить расходы;
Для соответствия требованиям ИБ.

Что же делать и как все «на самом деле»?
Нет никаких сомнений, что облака пришли всерьез и надолго. И с каждым годом их роль будет возрастать. Однако мы живем не в далеком будущем, а в 2020 году во вполне определенной ситуации. Что же делать с облаками, если вы не стартап, а классический корпоративный заказчик?

Облака – это прежде всего место для сервисов с непредсказуемой или ярко выраженной сезонной нагрузкой.
В большинстве случаев сервисы с предсказуемой стабильной нагрузкой дешевле содержать в собственном ЦОД.
Начинать работу с облаками необходимо с тестовых сред и низкоприоритетных сервисов.
Рассмотрение размещения информационных систем в облаке начинается с разработки методики выхода из облака в другое облако (или назад в собственный ЦОД).
Размещение информационной системы в облаке начинается с разработки схемы резервного копирования в контролируемую вами инфраструктуру.

===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_virtualizatsija (Виртуализация), #_oblachnye_vychislenija (Облачные вычисления), #_servernoe_administrirovanie (Серверное администрирование), #_cloud, #_oblako (облако), #_chastnoe_oblako (частное облако), #_private_cloud, #_virtualizatsija (
Виртуализация
), #_oblachnye_vychislenija (
Облачные вычисления
), #_servernoe_administrirovanie (
Серверное администрирование
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 25-Апр 16:42
Часовой пояс: UTC + 5