И снова про облака, не только плюсы
Всем привет. Это статья должна рано или поздно появится. Ведь мы видим много статей из серии «Облако- это лучшее, что могло произойти с нами!», «Как организация перешла в облачную инфраструктуру и сэкономила N денег»… Только периодически в комментариях появляются записи, что в некоторых случаях, облака- это не совсем то, что надо. Давайте, будем честными и сопоставим доходы с расходами. А также посмотрим на очевидные минусы, про которые принято молчать.
Изначально при написании статьи хотел охватить абсолютно все и самый весомый аргумент- это конечно цена. Есть таблицы по сравнению некоторых облачных провайдеров, но в данной статье «не про то». Мы будем сравнивать своё железо+ свои силы по администрированию и…. коллакейшен у тех самых хостингов, которые предоставляют такие услуги. Надо понимать где находится грань, между покупкой облачных ресурсов и покупкой своего железа для дальнейшего использования в своей рабочей среде. А также, что совершить ошибку может не только ваш системный администратор, но и сотрудник облачного провайдера, а страдать вы будете точно также.
Также я ни в коем случае не хотел захейтить всех провайдеров предоставляющих «облачные» услуги. Да, я читал например такие статьи habr.com/ru/company/activecloudru/blog/415483 (и #comment_18825847) и понимаю, что будет ряд негатива. Раньше облака, продумывались как средство для решения задач высокой нагрузки т.е. появилась нагрузка — купили на 2–3 дня серверов, снизилась — отдали обратно.
Одним из главных плюсов использования облачной платформы, по моему мнению это:
1. Снижение затрат на закупку оборудования- ведь покупаются только ресурсы, которые необходимы. Если не нужны, то просто удаляем и не платим- удобно.
2. Нет необходимости держать в штате специалистов, которые будут обслуживать сервера на аппаратном уровне. Клиент не думает, что находится на физическом уровне- все решается специалистами облачного провайдера.
3. Бесконечное масштабирование в рамках ЦОД и геораспределенность. Любое желание клиента для повышения отказоустойчивости бизнес приложения.
4. Возможность купить услуга сервис и не тратить ресурсы своих системных администраторов на обслуживание.
5. VM и необходимые сервисы, устанавливается (и удаляется впрочем тоже) одним кликом мышки.
6. Отпадает необходимость мониторить часть инфраструктуры (имеется ввиду консистентность данных raid, коммутаторы и т.п.)- все делают специалисты облачного провайдера.
Минусы:
1. Цена. Покупка своих серверов, может окупиться уже через 1 год. А при покупке облачных- у вас есть только услуга. Штат специалистов, также рассматривается.
2. «Виртуальное- не совсем реальное». Тут все ресурсы, которые покупаются у провайдера- CPU, RAM, SSD и скорость сети. Мы все понимаем, что есть ресурсы на уровне хоста и на уровне VM. Как же нам проверить, что мы действительно получаем 100% ресурса процессора и диска?
3. Отказоустойчивость и SLA, которая предоставляется провайдером, далека от мечты маркетолога.
4. «На игле». Провайдер пытается удержать клиента у себя и делает решения в рамках своей экосистемы.
Как видите, подробнее я буду описывать только минусы. Ведь о плюсах пишут практически везде, это в основном корпоративные блоги компаний предоставляющих подобные услуги.
Начинаем с цены.
Небольшое отступление. Описанное ниже, в рамках розничной покупки серверов. Цены усредненные. Если у вас крупная компания или хостинг, мы все прекрасно понимаем что уровень скидок на покупку оборудования в зависимости от объема может достигать 20–60% (а иногда и выше). Это дополнение к статье, все и так понимают за что переплачивают.
В качестве отправной точки возьмем стандартный сервер с следующими характеристиками:
| Комплектующие | Примерная стоимость | Количество | Стоимость по количеству |
| MotherBoard X11DPi-NT | 50000 | 1 | 50000 |
| INTEL CPU Silver 4214 | 57000 | 2 | 114000 |
| RAM 16Gb | 7500 | 16 | 120000 |
| INTEL SSDSC2KB96 (970Gb) | 13000 | 4 | 52000 |
| RAID controller ASR 8805 | 38000 | 1 | 38000 |
| SATA HGST HUS724020ALA640 (2000Gb) | 14000 | 4 | 56000 |
| Корпус с БП 825TQ-563LPB (2U) | 27000 | 1 | 27000 |
| Доплата за хороший корпус | 60000 | 1 | 60000 |
| Итого за 1 сервер | 517000 |
Диски в рамках железа будут в RAID10 т.е. цена будет сопоставима и скорость существенно выше.
Для наглядности я взял такие же VM с такими же характеристиками. Выбор провайдеров я определил сам, можете также посчитать для других. Повторюсь, данная статья не рассматривает сравнение провайдеров, а сравнение стоимости облака к собственному железу. Ниже конфигурация провайдеров, CPU 24cores, RAM 256GB, SSD 2TB, HDD 4TB.
| Облачный провайдер | За месяц | За 1 год | за 3 года |
| SELECTEL VPC | 137326 | 1647912 | 4943736 |
| SELECTEL VMWARE | 150432 | 1805184 | 5415552 |
| SELECTEL VMWARE GOLD | 162672 | 1952064 | 5856192 |
| YANDEX 5% | 71211 | 854532 | 2563596 |
| YANDEX 20% | 77376 | 928512 | 2785536 |
| YANDEX 100% | 79997 | 959964 | 2879892 |
| MCS MAILRU | 126880 | 1522560 | 4567680 |
| RTCLOUD* | 175156 | 2101872 | 6305616 |
* в рамках rtcloud я взял сервер с конфигурацией RAM-20Гб, CPU- 4Ггц (типа 2 ядра по 2Ггц), FAST HDD- 167Гб. И умножил на 12 (13263×12+16000 за 4 Тб HDD)
** По яндексу, еще необходимо учитывать стоимость исходящего трафика. Selectel дает 3Тб проходящего трафика на один проект, далее плата за 1 гб. В MCS MAILRU трафик полностью бесплатный.
Соответственно, мы понимаем, что в среднем гарантия на все комплектующие — 3 года. Поэтому будем считать, что через 3 года, данный сервер мы просто выкинем.
Также за данный сервер мы будем отдавать 6000–10000 (2-х юнитовый сервер с 2 мя блоками питания) в зависимости от того, какой колокейшн выберем. Возьмем по максимуму
12×10000=12000×3=360.000
Следовательно, за 3 года мы отдадим 360.000+517.000=877.000р. Это за 3 года пользования своим сервером, который после эксплуатации можно отдать нуждающимся стартапам или использовать для тестового полигона.
По цифрам таблицы провайдеров все ясно. Мы заплатили и получили услугу.
Сейчас многие будут писать: «Ну это и так ясно, капитан очевидность. А как же амортизация, зарплата админам, которые будут обслуживать эти сервера и делать для тебя крутые штуки типа live migration и др. Лицензии VMWare например и т.п. Отдельная покупка хранилки или организация распределенного хранилища» Да согласен. Руководству необходимо принять решение в зависимости от своих требований. Это только первый пункт. Поехали дальше.
Забираем к себе 4 системных администраторов и платим каждому по 200.000р (да и считаю что еще + 200.000 будут уходить в качестве налогов- это много и наверное находится в мечтах наших чиновников). Следовательно:
4×400000=1600000 в месяц. И в год 19.200.000 на зарплаты этим раздолбаям высококвалифицированным сотрудникам.
Значит после 20 серверов с такой конфигурацией выгоднее брать своих специалистов и обслуживать. По отношению к облаку, которое предоставляет такой сервер за 1 млн.рублей в год. Если ваш хостинг дороже, то значит и количество серверов по отношению к 4 м специалистам будет меньше.
«Виртуальное- не совсем реальное»
CPU. Одни провайдеры, конкретно говорят, что не лимитируют производительность процессора т.е. взял 4 ядра и можешь грузить сколько необходимо. Другие провайдеры, например amazon, yandex указывают, что можно не покупать 100% мощности процессора, а выделенный процент и цена будет меньше. Также есть понятие «Допустимая нагрузка на сервер», при которой клиенту сообщают «У вашего сервера слишком высокая нагрузка на CPU, вам необходимо перейти на тариф по дороже». Также не забываем про оверселлинг.
RAM. Не буду останавливаться на этом моменте. Проверяйте /proc/meminfo. И пробуйте занять весь объем ОЗУ на всех VM, которые купили- для тестов. Сейчас таких проблем нет и обычно провайдеры выдают ОЗУ честно.
IOPS. Это тот параметр, который облачный провайдер режет очень сильно и неявно. Проводить замеры fio надо всегда. Но вывод один: Многие облачные провайдера перешли к схеме «Чем больше объема взял, тем больше iops получил». Например, когда тестировал облако от яндекс, до 60 гб я не заметил разницы при использовании HDD и SSD, все слишком неявно. А также обратите внимание на SLA, которые относится к данному параметру- у всех этот параметр размыт настолько, что можно просто сказать «Мы вам даем 10000 IOPS, но по факту вы получаете 400. Для достижения эффекта в 10000 вам необходимо купить объем более 600Гб. И тут мы вас тоже поимеем есть нюанс т.к. SLA по данному параметру не более 75%, а при определенных условиях не более 50%».
Скорость порта. Тут по разному, некоторые провайдеры действительно дают честный гигабит. Другие только 250 мбит\сек. В основном тут редко возникают проблемы и все вполне решаемо.
SLA и отказоустойчивость.
Как же нам проверять, что мы получаем все ресурсы, которые купили. Вот тут и нужны специалисты, которые будут это мониторить (как организовать данный мониторинг- за рамках данной статьи). А также на этапе подписания договора, необходимо сразу договорится. Например, в случае несоответствия по SLA определенного параметра, ущерб возмещается. А также тонкий момент- кто выявил и вовремя сообщил. Если сам провайдер, то согласно договору. Если же провайдер решил умолчать, а вы заметили это на своих системах мониторинга, то спустя 2 дня сообщить о этом и доказать- тогда возмещение в 2 раза больше. Это поможет вам получить, то качество услуг, которое предоставляет провайдер.
Все лидеры облачных услуг, рассказывают о том, как все настроено и в случае взрыва дата центра, все ваши задублированные данные в момент времени будут работать в другом дата центре. По факту, даже при покупке сверх отказоустойчивого облака будут возникать проблемы, которые будут заставлять тебя самому заботится о доступности своих сервисов- это и рекомендации провайдера Anti-Affinity. И «забота» в качестве предоставления услуг своих специалистов за отдельные деньги, для настройки сервисов внутри облака- если один из серверов провайдера выйдет из строя. Вот тебе, забота о клиентах.
«На игле»
Начнем с того же yandex и amazon. Сделали своё api, сделали документацию и «разбирайтесь». Другие пошли путем openstack- тут единое api для всех, что добавляет всю мощь управления над многими сервисами.
Истории из личного опыта приводить не буду. Могу сказать только одно, если случится низкоуровневая проблема на блочном уровне- никто вам не поможет, разбирательство по данным проблемам будет проходить долго, постоянно надо что то доказывать обладая данными той абстракции, которую купил. Также как и проблемы с ОЗУ, вы не можете прогнать memtest и проверить, что все действительно хорошо- надейтесь на сознательность провайдера.
Резюмирую. Что вообще я хотел сказать данной статьей?
1. Уважаемые представители облачных услуг. Делайте ваши сервисы еще качественнее и не заставляйте клиентов переплачивать вам за повышение надежности своего приложения покупкой дополнительных ресурсов. А также делайте скидки и делайте шаг в этом направлении первыми.
2. Уважаемые клиенты. Старайтесь строить гибридные облака и не зависеть полностью от облачных провайдеров. В будущем этот рынок будет расти и сужаться цены будут примерно на одном уровне и будут помаленьку расти вверх. Многие крупные компании начинают строить свои дата центры свои сервисы с минимальным участием облачных поставщиков.
3. Не могу не затронуть тему безопасности. Покупайте частные облака, которые практически в 1,5 раза дороже публичных или….
4. Руководителям IT подразделений, следует подходить более жестче к выбору облачного поставщика. Взвесить все возможные риски и спровоцировать пожар, до его начала (жесткие тесты).
