Comments 42
Однако виртуальная машина — это просто пустой контейнер. После установки VM дальнейший процесс работы ничем не отличается от работы с физическим сервером. Вам все равно придется развернуть приложения, настроить свои ИТ-процессы и т. д.
Но вам не нужно будет парится о железе. И это на самом деле довольно большой плюс в силу того, почему виртуалка лучше.
Виртуалку проще размножить и зафризить.
Виртуалку проще ограничить.
Ну и так далее.
А кто сказал, что на своих серверах нельзя сделать виртуалки и также фризить, запускать, размножать?
Суть статьи можно сократить до следующей информации. Отдавая свои данные на сторону вы рискуете бизнесом. Провайдер рискует контрактом. Поэтому вам всегда надо два облака. При чем на самом деле независимых. И кросбэкап.
Еще с виртуалки можно снять снапшот и порытся в памяти! И шапочка не поможет! Поэтому нормальные параноики используют железные сервера, а продвинутые — свои железные сервера и, до кучи, с датчиками.
Нормальные параноики и корпорации, которые работают с важными данными держат сервера у себя под охраной. Все остальное вроде от лукавого.
конечно, а в идеале дома под рукой, отключеннным от сети.
Шифрование и датчики все решают (чтобы не снять дамп с оперативки финтом ушами и морозилкой).
Но вам не нужно будет парится о железе.А я бы парился о железе, на котором крутится виртуалка. Фиг знает, какой оно потрёпанности и поколения.
Ну вот hetzner совсем плох с этим, но виртуалочки нормально работают)
Давайте не будет лишний срач разводить про hetzner?
При аренде серверов (xeon'ы есессно) у меня всегда были свежие диски (3-7 дней наработки всего) и само железо работало как часы годами.
Никакого срача. У меня в целом к ним нет никаких претензий, исключая кривую настройку сети)
Нынче они доволно круты. Я застал время когда они начинали. Это было весело. Косяки были очень странные: на уровне уборщица порвала оптику. С другой стороны атмосфера была доверительная. Например, один раз наш бухгалтер закосячил и не платил им три месяца, а они все это время не замечали. Да и когда заметили не выключили, а письмо написали. При чем походу писал немец, с помощью гугл транслейта. :)
Но вам не нужно будет парится о железе.
Вот тут как раз-таки всё абсолютно наоборот. Покупая сервер с SSD, ты получаешь именно SSD на установленной ОС. Виртуальный сервер с диском (как часто бывает): это железный диск плюс слой торможения на виртуализации. И хорошо еще, если железом будет SSD, а не далекий SAN с HDD дисками.
Далее процессор. Выбирая железный сервер, человек осознанно выбирает и процессор. Без слоя торможения, без конкурирования за память из-за соседней виртуалки, которая решила именно активно использовать RAM.
Я уже кучу раз видел примеры, когда пытались продавать виртуалки без описания, что за процессор, что за память и т.д. Для менеджмента это упрощение, для клиента это падение производительности.
Я уж не говорю, что если тебя отдалили от железа, то тебе будет дороже использовать базу, т.к. если менять процессоры с ядрами по 4 Ггц на процессоры с ядрами по 2 Ггц, то для компенсации падения производительности придется использовать больше ядер, а значит — больше лицензий для той же базы (см. ссылку — каждое ядро Enterprise версии стоит $14 000)
Про SSD. Если ты берешь железный сервер с PCI (или M.2) дисками, то они могут общаться с RAM без использования процессора — см. Direct Memory Access. В случае виртуализации мы будет тратить еще и процессор, что еще больше будет убивать производительность.
Мораль: если вам не важна производительность, а требуется бумажная простота, то выбирайте виртуализацию. Однако если ваш сервер должен работать как можно быстрее, есть как можно меньше ресурсов, а вы готовы тратить своё время на изучение возможностей железа, то виртуализация будет вам только вставлять палки в колеса.
а не далекий SAN с HDD дисками.
SAN в случае использования NPIV может быть существенно быстрее всех других способов соединения для виртуалок. Собственно это единственный реальный метод использовать виртуализацию для тяжелых баз данных.
"быстрее" по времени отклика?
SAN — это последовательность "сеть" — "ОС SAN'а" — "диск" — "ОС SAN'а" — "сеть".
Как SAN может работать быстрее, если на железном компе не будет ряда посредников?
SAN — это последовательность "сеть" — "ОС SAN'а" — "диск" — "ОС SAN'а" — "сеть".
Какая ещё ОС 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 во всяких точках обработки банковских транзакций.
Забавно что единственное разумное решение, которое сейчас индустрия видит для таких задач, это распределенные инмемори хранилища. Не знаю взлетит ли.
Я согласен с тобой по поводу ускорения, согласен по поводу быстрой работы.
Однако я говорил про то, что зачастую вместо всех этих вот наворотов используют абстрактную фразу "Disk Storage", а на железном сервере ты сделаешь или подобный SAN, или просто поставишь PCI SSD. Самое главное — ты получишь максимальную скорость, какую может выжать железо.
Забавно что единственное разумное решение, которое сейчас индустрия видит для таких задач, это распределенные инмемори хранилища.
Я вижу сейчас постепенный откат от технологий виртуализации в пользу контейнеров, которые дают схожий результат по конфигурации, однако не имеет явных проблем с производительностью. А im-memory во многом — это следствие микросервисной архитектуры, вынос ConcurrentMap в отдельный процесс просто.
Самое главное — ты получишь максимальную скорость, какую может выжать железо.
Но не получишь финасовую гибкость. Мне кажется облака вообще немного не о технике как токовой. Самая главная фишка в них это возможность гибко настраивать количество ресурсов и за счет этого сглаживать пики.
Например в кровавом ентерпрайзе облаками пользуются когда надо увеличить именно вычислительную мощность. Например просчитать квартальные отчеты: поднял 100 инстансов в облаке, скормил им входные данные, получил на выходе кучу pdf, положил. Если подойти к этому с головой, то можно съэкономить и деньги и время.
вынос ConcurrentMap в отдельный процесс просто
В случае банков в отдельный процесс уже недостаточно. Нужно в изолированный аппаратный кластер, независимый от питания и географически разделенный. Идея в том, что данные только в памяти и держатся.
Другими словами: есть ферма из 50 серверов с общим объемом оперативки в 50Т. И именно в этой памяти вся информация по счетам клиентов и держится. Если весь кластер сдохнет, то восстнавливаться сутки с логов повтора, которые пишутся асинхронно, а uptime должен быть не ниже четырех — пяти девяток.
В случае банков в отдельный процесс уже недостаточно. Нужно в изолированный аппаратный кластер, независимый от питания и географически разделенный. Идея в том, что данные только в памяти и держатся.
Нужны пруфы, что большинству банкам именно нужно (а не кто-то где-то применил). И почему именно "банкам"? Яндексу и Гуглу это не нужно?
Самая главная фишка в них это возможность гибко настраивать количество ресурсов и за счет этого сглаживать пики.
Ты говоришь про банки, но в банке пик идет сразу один для всех. Выборы в США — и пик по торговле на всех биржах. Потому тут как раз-таки облака не шибко полезны.
поднял 100 инстансов в облаке, скормил им входные данные, получил на выходе кучу pdf, положил
Если мы говорим про крупную организацию, то сразу добавь "заполнил кучу бумажек, поговорил с бюрократами". И чем нам облака помогут?
Тут ведь какое дело. Если народ квалифицированный и есть ресурсы, то облака не особо и нужны (ферму люди смогут поднять для себя, поддерживать для себя, а не пытаться подстроить свои процессы под нужны облачного хостера). Если же мы хотим "делегировать задачи распределения ресурсов", то нам никто не даст гарантий, что ресурсы будут расходоваться эффективно. Ну то есть как в моем примере с базой: хостеру просто выгоднее держать базу на слабых процессорах — так денежный оборот в итоге больше.
Яндексу и Гуглу это не нужно?
Думаю нет. У них нет такого объема согласованной информации. А поисковые индексы, пользовательские файлы и прочее легко делить. Другие технологии, другая логика, другой уровень ответственности (точнее никакой ответственности).
ферму люди смогут поднять для себя,
Я имел ввиду что она будет простаивать 70% времени.
У них нет такого объема согласованной информации.
Тут нужны пруфы, всё это голословные высказывания.
Я имел ввиду что она будет простаивать 70% времени.
Вот именно поэтому я и говорю, что облака нужно гнать в шею, если идет такой подход. См. описание работы stackoverflow — заметь, что там серверы нагружены еще меньше, а самих железок не так много. И это один из самых нагруженных сайтов в мире.
И качество работы у них такое не потому, что стремились "резать косты", а потому что упор именно на скорость, качество, удобство.
Нужны пруфы, что большинству банкам именно нужно (а не кто-то где-то применил)
К банкам применяются требования PCI DSS, которые говорят о множестве вещей, в том числе о геораспределении и иных элементах надёжности.
К банкам применяются требования PCI DSS, которые говорят о множестве вещей, в том числе о геораспределении и иных элементах надёжности.
Даже если принять на веру, что все это действительно выполняется так, как написано на бумаге (мы ведь знаем, как происходит сертфикация ПО в РФ?), то не вижу никаких вообще сложностей. Или ты действительно считаешь, что Distributed Transactions на распределенную базу (при условии, что она находится в одной стране, просто в разных городах) будет работать долго?
На деле всё совсем-совсем не так. Просто в банках на многих постах стоят люди с плохим инженерным образованием. И им намного проще делегировать задачу "поддержка 1000 серверов" компании аутсорсеру, нежели работать с отделом. Компании в целом так не выгодно, а вот конкретному менеджеру — как раз очень даже, а верхушка не сможет аргументировать позицию "всем занимаемся сами".
Отсюда и получаем, что сначала внедряется аутсорсер, производительность и качество падает (ибо у него только одна цель — формальное соответствие договору), банк переходит на новый, более дорогой, тарифный план и т.д.
Однозначно истолковывать как абсолютное зло, нам кажется, не корректно.
Я выше и написал, где облака осмыслены, а где приводят к проблемам.
Большинство задач закрываются достаточно успешно.
Нужны независимые данные, или ремарка "как мне кажется". То, что я вижу регулярно: приходит облачный провайдер и заменяет железные процессоры на виртуальные, причем далеко не всегда один виртуальный процессор работает на одном железном.
Так решение спускается сверху, откатить ситуацию назад бывает довольно сложно. А потому в ряде случаев облачных интеграторов пытаются убрать как можно быстрее.
Я ни в коем случае не говорю, что ваш сервис такой. Однако, из-за подобных действий страдают многие облачные решения, причем, возможно, и ваше тоже.
Правда вот при этом не получается продать много дешевых машинок.
Если вы вслепую принимаете заявление «Мы заботимся обо всем», я могу уверить вас, что у вас есть ложные ожидания и у вас будет плохой опыт сотрудничества с поставщиком облачных услуг.
из личного опыта, последние два года активно работаю с AWS. И вот что мне нравится — так это то, что я полностью отстранен от проблем аппаратной части и могу полностью сконцентрироваться на программной. И это большой плюс.
Когда вам не нужно беспокоиться о битых блоках на жестких дисках, настройке рейдов, батареек, обновлении прошивок на рейд контроллерах, поиску совместимости аппаратных комплектующих и т.п. прелестей. Так сказать на контрасте после 5 лет работы с Хецнером. Сколько же там раз приходилось чинить рейды, и иногда случаи были не тривиальными и забирали очень много нервов и времени. Так же много раз были проблемы с памятью, в том числе с ECC, когда проблему были найти очень трудно, а иногда и невозможно, по крайней мере в удаленном режиме. Ибо тех поддержка у них довольно таки прямолинейная — мы запустили memtest после N часов ошибок нет, так что проблема на вашей стороне, разбирайтесь.
Естественно, что ни один хостер вам не гарантирует 100% SLA, скажем так за разумные деньги. Ибо чтобы обеспечить дополнительную 9ку после запятой необходимо вкладывать денег по экспоненциальной кривой.
И конечно, даже на AWS вы должны делать бекапы и процедуры Disaster recovery. Ибо молнии и другие форсмажорные обстоятельства никто не сможет отменить.
Сказки, которые Вам расскажут облачные провайдеры