Перевод этой статьи – наш вклад в ликвидацию безграмотности потребителей облачных услуг. Будьте бдительны!
Если вы задумываетесь о миграции в облако вот Вам несколько утверждений, которые при разговоре с облачным провайдером «маякнут» о том, что здесь что-то не так.
Ложь # 1: Все соглашения об уровне предоставления услуг (SLA) по использованию облачных сервисов одинаковы.
Это правда: многие провайдеры по умолчанию ставят цифру 99,95%, когда речь идет об уровне доступности. Но что нужно сделать, чтобы получить правдивые цифры?
Посмотрите на это следующим образом: отличная реклама подтолкнула Вас на покупку автомобиля, но при совершении сделки Вы обнаруживаете маленькую звёздочку рядом с процентной ставкой, обязующую Вас сделать огромный первоначальный взнос. То же самое происходит с облачными SLA.
Например, облачный провайдер «A» может иметь SLA 99,95%, но когда вы выясняете всю подноготную, то получается, что этот SLA соответствует этому уровню только в том случае, если вы выполняете определенные действия. Например, вам, возможно, придется заключать контракты с провайдером «А» только в нескольких зонах доступности или покупать их в определенных аспектах своего решения (кстати, оба условия увеличивают ваши затраты). Это нормально только в том случае, если Вы так и планировали сделать.
С другой стороны, облачный провайдер «B», может дать вам SLA 99,95% без привязки к тексту: у вас просто есть SLA 99,95% на каждую виртуальную машину, а в договоре четко определён период. SLA полностью отвечает за них, и вам не нужно беспокоиться о том, чтобы изменить архитектуру вашей системы, которая будет охватываться SLA.
Поэтому, если кто-то скажет вам, что все облачные SLA одинаковы, достаньте лупу, там где-то может скрываться звездочка.
Ложь # 2: Виртуальные машины (VM) гораздо проще в использовании, чем физические серверы.
Как и в любой лжи, здесь есть доля правды. Так, например, виртуальную машину очень легко установить, и Вам не придётся проходить весь этот цикл с покупкой серверов и шкафов для них, установкой, налаживанием инфраструктуры для их деятельности. А так же, вы можете настроить операционную систему в одно мгновение.
Однако виртуальная машина — это просто пустой контейнер. После установки VM дальнейший процесс работы ничем не отличается от работы с физическим сервером. Вам все равно придется развернуть приложения, настроить свои ИТ-процессы и т. д.
Ложь # 3: Большинство компаний перемещают весь дата центр в облако.
Малые компании? Может быть. Средние и крупные компании? Нет. Они могут перемещать часть своего дата центра в облако, чтобы сделать некоторые ИТ-операции более гибкими и быстрыми, но это очень редко происходит со всем массивом данных.
Причина проста: чем крупнее компания, тем больше факторов, препятствующих переходу в облако она имеет: множество бизнес-единиц, устаревших систем, мэйнфреймов, уже существующих ЦОДов и сторонние интеграции. Некоторые используемые приложения могут работать неправильно в облаке. Некоторые данные могут быть слишком секретными, чтобы когда-либо существовать в облачной среде. Как результат: гибридная среда — это факт жизни.
Ложь # 4: Вы сэкономите массу денег в долгосрочной перспективе с облаком.
Могут ли компании сэкономить деньги, перейдя в облако? Конечно. Но экономия на затратах — это не главная причина, почему компании мигрируют в облако. Компании могут переходить туда, потому что облако дает им большую гибкость, более быструю реакцию ответа, а также возможность быстрее перейти от капитальных расходов к операционным, тем самым, сократив количество затрат необходимых при запуске проекта, и быстрее выйти на рынок. Иногда (я знаю, это звучит еретично!), затраты компании на облако действительно будут расти. В этих случаях задача компании заключается в том, чтобы взвесить расходы и преимущества, которое дает облако, чтобы увидеть, что представляет наибольшую ценность.
Ложь # 5: Мы позаботимся обо всем!
В самом деле? В таком случае, вы будете доставлять мне кофе по утрам? Если вы услышите эту строку, немедленно спросите: «Что вы подразумеваете под «всем»?» Когда у вас есть четкое объяснение, предоставленное вам в документальном формате, сравните его с тем, что вы считаете «всем». Если они совпадут, вы можете продолжать сотрудничество. Если они отличаются, определите, что должно произойти, чтобы ваша интерпретация «все» была согласована с облачным провайдером.
Если вы вслепую принимаете заявление «Мы заботимся обо всем», я могу уверить вас, что у вас есть ложные ожидания и у вас будет плохой опыт сотрудничества с поставщиком облачных услуг.
Поделиться с друзьями
Комментарии (42)
Algoritmist
06.06.2017 13:14А кто это на фотографии?
ALexhha
06.06.2017 22:10Если вы вслепую принимаете заявление «Мы заботимся обо всем», я могу уверить вас, что у вас есть ложные ожидания и у вас будет плохой опыт сотрудничества с поставщиком облачных услуг.
из личного опыта, последние два года активно работаю с AWS. И вот что мне нравится — так это то, что я полностью отстранен от проблем аппаратной части и могу полностью сконцентрироваться на программной. И это большой плюс.
Когда вам не нужно беспокоиться о битых блоках на жестких дисках, настройке рейдов, батареек, обновлении прошивок на рейд контроллерах, поиску совместимости аппаратных комплектующих и т.п. прелестей. Так сказать на контрасте после 5 лет работы с Хецнером. Сколько же там раз приходилось чинить рейды, и иногда случаи были не тривиальными и забирали очень много нервов и времени. Так же много раз были проблемы с памятью, в том числе с ECC, когда проблему были найти очень трудно, а иногда и невозможно, по крайней мере в удаленном режиме. Ибо тех поддержка у них довольно таки прямолинейная — мы запустили memtest после N часов ошибок нет, так что проблема на вашей стороне, разбирайтесь.
Естественно, что ни один хостер вам не гарантирует 100% SLA, скажем так за разумные деньги. Ибо чтобы обеспечить дополнительную 9ку после запятой необходимо вкладывать денег по экспоненциальной кривой.
И конечно, даже на AWS вы должны делать бекапы и процедуры Disaster recovery. Ибо молнии и другие форсмажорные обстоятельства никто не сможет отменить.
mclouds
07.06.2017 06:34Именно поэтому мы предоставляем только облачные серверы. Вся аппаратная часть на нас. И наша задача обеспечить клиенту среду для ЕГО задач, бизнеса и дела. Целиком поддерживаем вашу точку зрения. )
ScarletFlash
08.06.2017 05:18Самого интересного – про то, что безлимитных тарифов не бывает – не рассказали. Это особенно касается SSD.
mclouds
08.06.2017 10:20Смотря, что имеется ввиду под безлимитным тарифом.
ScarletFlash
10.06.2017 11:53У многих нетоповых хостингов встречал безлимиты и на SSD, и на трафик. Понятно, что маркетинговый ход, но народ же ведется.
mclouds
10.06.2017 13:07У нас на текущий момент не установлены какие-либо лимиты на SSD и трафик. В виртуальный сервер входит цена за 100 мбит канал, его можно утилизировать как удобно.
SirEdvin
Но вам не нужно будет парится о железе. И это на самом деле довольно большой плюс в силу того, почему виртуалка лучше.
Виртуалку проще размножить и зафризить.
Виртуалку проще ограничить.
Ну и так далее.
acmnu
А кто сказал, что на своих серверах нельзя сделать виртуалки и также фризить, запускать, размножать?
Суть статьи можно сократить до следующей информации. Отдавая свои данные на сторону вы рискуете бизнесом. Провайдер рискует контрактом. Поэтому вам всегда надо два облака. При чем на самом деле независимых. И кросбэкап.
nikitasius
Еще с виртуалки можно снять снапшот и порытся в памяти! И шапочка не поможет! Поэтому нормальные параноики используют железные сервера, а продвинутые — свои железные сервера и, до кучи, с датчиками.
SirEdvin
Нормальные параноики и корпорации, которые работают с важными данными держат сервера у себя под охраной. Все остальное вроде от лукавого.
nikitasius
конечно, а в идеале дома под рукой, отключеннным от сети.
Шифрование и датчики все решают (чтобы не снять дамп с оперативки финтом ушами и морозилкой).
alexeykuzmin0
Экранировать не забудьте, а еще всякие проверки целостности.
mclouds
На самом деле многие большие компании часть своих сервисом переводят в ЦОДы, организуя там свои выделенные зоны, закрытые от других стоек. Вход в эту зону через СКУД. Хранить свои сервисы только у себя, часто гораздо более затратно.
navion
Так и в облаках это делают. Наверняка для GE и USAF сделали выделенные сегменты Office 365 с хранением данных только на территории США.
mclouds
Определенные технические требования наверняка были выдвинуты, конечно )
ALexhha
зачастую по экономическим соображениям. Так как компаниям уровня яндекс/фейсбук и т.д. аренда такого количества серверов облаке стоила бы намного дороже содержания своих ДЦ
LoadRunner
SirEdvin
Ну вот hetzner совсем плох с этим, но виртуалочки нормально работают)
nikitasius
Давайте не будет лишний срач разводить про hetzner?
При аренде серверов (xeon'ы есессно) у меня всегда были свежие диски (3-7 дней наработки всего) и само железо работало как часы годами.
SirEdvin
Никакого срача. У меня в целом к ним нет никаких претензий, исключая кривую настройку сети)
acmnu
Нынче они доволно круты. Я застал время когда они начинали. Это было весело. Косяки были очень странные: на уровне уборщица порвала оптику. С другой стороны атмосфера была доверительная. Например, один раз наш бухгалтер закосячил и не платил им три месяца, а они все это время не замечали. Да и когда заметили не выключили, а письмо написали. При чем походу писал немец, с помощью гугл транслейта. :)
nikitasius
Hetzner славные ребята и на серверах там честный гигабит
Но, в виду новой реформы в РФ они стали на 18% дороже. Но, если нужны сервера — там самые выгодные тарифы.
mclouds
Адекватный провайдер всегда вам ответит что за оборудование он использует. Если это облако, как в нашем случае, то вплоть до на какой ноде непосредственно сейчас ваши сервисы, включая по каждой VM. Это не очень сложно )
imanushin
Вот тут как раз-таки всё абсолютно наоборот. Покупая сервер с SSD, ты получаешь именно SSD на установленной ОС. Виртуальный сервер с диском (как часто бывает): это железный диск плюс слой торможения на виртуализации. И хорошо еще, если железом будет SSD, а не далекий SAN с HDD дисками.
Далее процессор. Выбирая железный сервер, человек осознанно выбирает и процессор. Без слоя торможения, без конкурирования за память из-за соседней виртуалки, которая решила именно активно использовать RAM.
Я уже кучу раз видел примеры, когда пытались продавать виртуалки без описания, что за процессор, что за память и т.д. Для менеджмента это упрощение, для клиента это падение производительности.
Я уж не говорю, что если тебя отдалили от железа, то тебе будет дороже использовать базу, т.к. если менять процессоры с ядрами по 4 Ггц на процессоры с ядрами по 2 Ггц, то для компенсации падения производительности придется использовать больше ядер, а значит — больше лицензий для той же базы (см. ссылку — каждое ядро Enterprise версии стоит $14 000)
Про SSD. Если ты берешь железный сервер с PCI (или M.2) дисками, то они могут общаться с RAM без использования процессора — см. Direct Memory Access. В случае виртуализации мы будет тратить еще и процессор, что еще больше будет убивать производительность.
Мораль: если вам не важна производительность, а требуется бумажная простота, то выбирайте виртуализацию. Однако если ваш сервер должен работать как можно быстрее, есть как можно меньше ресурсов, а вы готовы тратить своё время на изучение возможностей железа, то виртуализация будет вам только вставлять палки в колеса.
acmnu
SAN в случае использования NPIV может быть существенно быстрее всех других способов соединения для виртуалок. Собственно это единственный реальный метод использовать виртуализацию для тяжелых баз данных.
imanushin
"быстрее" по времени отклика?
SAN — это последовательность "сеть" — "ОС SAN'а" — "диск" — "ОС SAN'а" — "сеть".
Как SAN может работать быстрее, если на железном компе не будет ряда посредников?
acmnu
Какая ещё ОС SAN? Данные в SAN передаются между хардварными устройствами и никогда не обрабатывются софтом (не будем об FCoE — никто в здравом уме это не использует). Сам стандарт сделан так, чтоб снизить задержки. По сути то что есть — чистая физика: скорость света и затраты на модуляцию/демодуляцию. Буферизация в этой сети практически отсутствует.
Фактически цепочка выглядит так.
fc-адаптер -> оптика -> fc-switch -> оптика -> fc-адаптер -> write-cache -> софт массива -> HDD/SSD
fc-switch апаратный, комутация происходит на уровне железа. Write-cache конечная точка для данных с точки зрения пользователя. Как только данные попадают во write-cache в ответ уходит сообщение об успешной записи (на кеше есть батарейка).
А с виртуализацией проблема том, что диск в любом случае выделяется через некоторую программную прослойку. Т.е. последовательность на самом деле такая
VM -> некая промежуточная память (буфер) -> гипервизор -> диск.
За последние годы алгоритмы существенно улучшились и скорость возросла (5-7 лет назад это был ад). Но все равно дело в этом буфере. Из-за него растет латенси. Кроме того, из-за использования центрального CPU для обслуживания этой очереди, существует теоретический предел пропускной способности. Алгортмы все время улучшаются, но все же этот предел есть, довольно велик в наше время, но есть.
В случае использования NPIV, виртуализируется сама fc-карта. И цепочка становится вот такой.
VM->FC-карта->SAN
В это схеме гипервизор только управляет работой fc, но данные через него не идут. Сам же SAN это давно откатаный и хорошо работающий механизм, как я говорил выше.
Вся эта машинерия не заметна на обычных сайтах, но в кровавом энтерпрайзе по-прежнему актуально. Нельзя дать виртуалке 2Gb и 400К TPS без NPIV или выделения личного контроллера с дисками. Ситуация отягощятся тем, что на x86 все это в принципе пока плохо сделано. Отсюда гегемония Power/SPARC во всяких точках обработки банковских транзакций.
Забавно что единственное разумное решение, которое сейчас индустрия видит для таких задач, это распределенные инмемори хранилища. Не знаю взлетит ли.
imanushin
Я согласен с тобой по поводу ускорения, согласен по поводу быстрой работы.
Однако я говорил про то, что зачастую вместо всех этих вот наворотов используют абстрактную фразу "Disk Storage", а на железном сервере ты сделаешь или подобный SAN, или просто поставишь PCI SSD. Самое главное — ты получишь максимальную скорость, какую может выжать железо.
Я вижу сейчас постепенный откат от технологий виртуализации в пользу контейнеров, которые дают схожий результат по конфигурации, однако не имеет явных проблем с производительностью. А im-memory во многом — это следствие микросервисной архитектуры, вынос ConcurrentMap в отдельный процесс просто.
acmnu
Но не получишь финасовую гибкость. Мне кажется облака вообще немного не о технике как токовой. Самая главная фишка в них это возможность гибко настраивать количество ресурсов и за счет этого сглаживать пики.
Например в кровавом ентерпрайзе облаками пользуются когда надо увеличить именно вычислительную мощность. Например просчитать квартальные отчеты: поднял 100 инстансов в облаке, скормил им входные данные, получил на выходе кучу pdf, положил. Если подойти к этому с головой, то можно съэкономить и деньги и время.
В случае банков в отдельный процесс уже недостаточно. Нужно в изолированный аппаратный кластер, независимый от питания и географически разделенный. Идея в том, что данные только в памяти и держатся.
Другими словами: есть ферма из 50 серверов с общим объемом оперативки в 50Т. И именно в этой памяти вся информация по счетам клиентов и держится. Если весь кластер сдохнет, то восстнавливаться сутки с логов повтора, которые пишутся асинхронно, а uptime должен быть не ниже четырех — пяти девяток.
imanushin
Нужны пруфы, что большинству банкам именно нужно (а не кто-то где-то применил). И почему именно "банкам"? Яндексу и Гуглу это не нужно?
Ты говоришь про банки, но в банке пик идет сразу один для всех. Выборы в США — и пик по торговле на всех биржах. Потому тут как раз-таки облака не шибко полезны.
Если мы говорим про крупную организацию, то сразу добавь "заполнил кучу бумажек, поговорил с бюрократами". И чем нам облака помогут?
Тут ведь какое дело. Если народ квалифицированный и есть ресурсы, то облака не особо и нужны (ферму люди смогут поднять для себя, поддерживать для себя, а не пытаться подстроить свои процессы под нужны облачного хостера). Если же мы хотим "делегировать задачи распределения ресурсов", то нам никто не даст гарантий, что ресурсы будут расходоваться эффективно. Ну то есть как в моем примере с базой: хостеру просто выгоднее держать базу на слабых процессорах — так денежный оборот в итоге больше.
acmnu
Думаю нет. У них нет такого объема согласованной информации. А поисковые индексы, пользовательские файлы и прочее легко делить. Другие технологии, другая логика, другой уровень ответственности (точнее никакой ответственности).
Я имел ввиду что она будет простаивать 70% времени.
imanushin
Тут нужны пруфы, всё это голословные высказывания.
Вот именно поэтому я и говорю, что облака нужно гнать в шею, если идет такой подход. См. описание работы stackoverflow — заметь, что там серверы нагружены еще меньше, а самих железок не так много. И это один из самых нагруженных сайтов в мире.
И качество работы у них такое не потому, что стремились "резать косты", а потому что упор именно на скорость, качество, удобство.
FlashHaos
К банкам применяются требования PCI DSS, которые говорят о множестве вещей, в том числе о геораспределении и иных элементах надёжности.
imanushin
Даже если принять на веру, что все это действительно выполняется так, как написано на бумаге (мы ведь знаем, как происходит сертфикация ПО в РФ?), то не вижу никаких вообще сложностей. Или ты действительно считаешь, что Distributed Transactions на распределенную базу (при условии, что она находится в одной стране, просто в разных городах) будет работать долго?
На деле всё совсем-совсем не так. Просто в банках на многих постах стоят люди с плохим инженерным образованием. И им намного проще делегировать задачу "поддержка 1000 серверов" компании аутсорсеру, нежели работать с отделом. Компании в целом так не выгодно, а вот конкретному менеджеру — как раз очень даже, а верхушка не сможет аргументировать позицию "всем занимаемся сами".
Отсюда и получаем, что сначала внедряется аутсорсер, производительность и качество падает (ибо у него только одна цель — формальное соответствие договору), банк переходит на новый, более дорогой, тарифный план и т.д.
mclouds
Виртуализация очень общее понятие. Для каких-то задач и уровня ответственности — применимо и очень даже, где-то не используется вовсе. Большинство задач закрываются достаточно успешно. Тут все-таки, мы считаем, подход должен быть разумным, взвешивая разные входные данные, учитывая сколько это стоит, а также беспрерывность работы. Однозначно истолковывать как абсолютное зло, нам кажется, не корректно.
imanushin
Я выше и написал, где облака осмыслены, а где приводят к проблемам.
Нужны независимые данные, или ремарка "как мне кажется". То, что я вижу регулярно: приходит облачный провайдер и заменяет железные процессоры на виртуальные, причем далеко не всегда один виртуальный процессор работает на одном железном.
Так решение спускается сверху, откатить ситуацию назад бывает довольно сложно. А потому в ряде случаев облачных интеграторов пытаются убрать как можно быстрее.
Я ни в коем случае не говорю, что ваш сервис такой. Однако, из-за подобных действий страдают многие облачные решения, причем, возможно, и ваше тоже.
vikarti
Есть хостеры кто подумал немного и большинство полезных фич виртуалок облачных — предоставляют на голом железе, со всеми бонусами такого подхода (https://noc.baremetalcloud.com/ например, бывшие newservers.com).
Правда вот при этом не получается продать много дешевых машинок.