Блог компании крок облачные сервисы

Photo by Victor Rodriguez on Unsplash

Часто мы получаем от клиентов (включая даже крупных) сообщения, в которых сквозит общий мотив: У %provider_name% нам не хватало 192 ядер, а у вас и 120 достаточно. Почему так?. Причем в последнее время из-за пандемии таких запросов стало больше. То ли потому что клиенты вышли в онлайн и почувствовали нехватку ресурсов из-за ажиотажного спроса и у других клиентов тоже, то ли потому что некоторые провайдеры из-за все того же высокого спроса на услуги стали плотнее упаковывать в облаке заказчиков.
Вот эта переподписка, которая обострилась, судя по всему, из-за Covid-19, сейчас волнует очень многих облачных пользователей. Поэтому мы постараемся ответить на наиболее распространенные вопросы и рассказать про инструмент, который позволит проверить наличие переподписки у вашего провайдера.
Может показаться, что эта тема уже не раз поднималась на Хабре и за его пределами, а статья будет полезной только совсем зеленым новичкам. Но мы не писали бы этот материал, если бы предполагаемый уровень осведомленности клиентов об этом явлении совпадал с реальным.

Что такое переподписка

Здесь все достаточно просто. К примеру, заказываете вы у провайдера определенные мощности ядра CPU, оперативную память, дисковое пространство. При этом вы не планируете постоянно использовать его на все 100%, следовательно, утилизация мощностей будет очень невелика. Провайдер тоже человек. Ему хочется зарабатывать, а значит, важно повышать утилизацию оборудования. Поэтому на свой страх и риск некоторые провайдеры перепродают выделенные для вас мощности другим клиентам из расчета, что ваши пиковые моменты никогда не произойдут в одно и то же время. А если и произойдут, то без какого-то сильного ущерба для бизнеса. Иными словами, может оказаться, что вы рассчитываете на конкретные мощности, проводите тесты и живете в уверенности, что в условную Черную пятницу приложение выстоит. А по факту информация от провайдера не соответствует действительности. Что в итоге? Падение, нервы, выяснение отношений?

Не все так однозначно.

Провайдеры: взгляд изнутри

Бесконечно можно делать три вещи: обновлять ленту инстаграма, скучать по офису на карантине и сравнивать облачных провайдеров.
Допустим, можно зайти с позиции цены. Каждый провайдер обозначает стоимость одного vCPU. Но что собой представляет этот vCPU, как его сопоставить с реальной производительностью? Проблема актуальна и для компаний, живущих у единственного провайдера, и для тех, кто арендует мощности сразу у нескольких. В последнем случае у этой задачки появляется дополнительная звездочка: нужно сопоставить тарифы разных провайдеров и привести их к единой сетке. У кого-то цены пониже, у кого-то процессоры помощнее.
Почему сложно сравнивать провайдеров? Во-первых, разные провайдеры по-разному распределяют ресурсы. Используют разное железо например, те же процессоры могут значительно отличаться. Конечно, надо сверить модель процессоров насколько они свежие. Однако, главное у всех разная переподписка. Она многократно усложняет расчеты: чтобы понять, сколько именно денег вы платите за конкретные мощности, требуется провести несколько замеров о них и поговорим.

Зная реальные цифры, уже можно сравнивать.
В ИТ-среде, особенно у клиентов, которые непосредственно в технической нише не работают, бытует мнение, что переподписка это чистое, рафинированное зло. На самом деле, это не так. Практически все клиенты, закупая мощности, закладывают некоторую их часть на компенсацию возможной переподписки. Если посмотреть на ситуацию со стороны провайдера, выходит, что средняя утилизация даже у очень крупных компаний (торговая сеть, банк) составляет буквально 5-7%. Это ничтожно мало. Как провайдеру бороться с такой низкой утилизацией?

Самое первое, что приходит на ум hyper-threading. Режим многопоточности включен абсолютно у всех провайдеров. В некотором смысле, он уже является переподпиской. Кто-то на этом останавливается, кто-то идет дальше. Здесь все зависит от целевого сегмента провайдера. Заказчики enterprise-уровня тщательно следят за показателями, умеют мониторить загрузку процессоров. Мыслят они приблизительно так: на своем сервере хочется иметь загрузку ЦП на уровне 15-20%. В облаке можно не скромничать и выжимать все 40-50%. И действительно нагружают. Переподписывать в такой ситуации как минимум некультурно. В некоторых случаях имеет смысл разве что перебалансировать нагрузку. Перенести сильно нагруженную машину на хост к менее загруженной, чтобы физический сервер был сбалансирован.
Если целевая аудитория компании частные лица, ситуация меняется. Допустим, Васе Доу (или Джону Пупкину) понадобилась виртуальная машина. Он хочет разместить на ней сайт мистервася.рф. Потенциальное количество его уникальных посетителей 3 с половиной человека в год. То есть сайт должен работать стабильно, но нагрузка у него будет очень скромная. Исходя из этих требований, Вася-Джон не захочет платить за сайт много денег. А крупному провайдеру будет нерентабельно отдавать виртуальную машину за сумму, комфортную для нашего героя. Компания, специализирующаяся на небольших клиентах, с радостью предоставит ему ВМ. Не потому что у нее процессоры намного дешевле или стойки хуже. Дело в переподписке. Enterprise-провайдер на одном физическом хосте может разместить 25-30 виртуальных машин, а компания поменьше 120-130. Чем менее требовательна к ресурсам целевая аудитория, тем большую переподписку можно себе позволить. И тем дешевле будет обходится каждая виртуальная машина для всех действующих лиц.
На самом деле, величина переподписки в чистом виде заказчику не интересна. Для него важно, сколько ресурсов он получит, нагружая систему. Так зачем же, если все устраивает, измерять переподписку своего провайдера?
Объективных причин всего две. Первая если вы чувствуете, что переплачиваете за мощности. Вторая если тормозит то, что тормозить не должно. В обоих случаях действительно имеет смысл замерять переподписку у нескольких провайдеров и переехать туда, где она ниже. Причем настолько ниже, чтобы решить все возникшие проблемы за те же или меньшие деньги.

Инструменты измерения переподписки

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

Итак, поехали.
Нам понадобится две виртуальные машины CentOS 7.x по 1 vCPU, так как мы тестируем производительность одного ядра.
Предварительно скачаем сам скрипт тестирования:

@vm1: curl https://storage.cloud.croc.ru/cloud-tests/perf.sh > perf.sh; chmod +x perf.sh@vm2: curl https://storage.cloud.croc.ru/cloud-tests/iperf.sh > iperf.sh; bash iperf.sh

@VM1 на данной ВМ будем запускать все необходимые нам тесты
@VM2 потребуется нам для тестирования сетевой подсистемы, поэтому установим сюда только необходимые нам утилиты
C помощью утилиты NBench замеряется скорость выполнения различных математических операций. Соответственно, чем она выше, тем лучше.

Запускаем тест на производительность CPU:

@vm1./perf.sh cpu

После первого шага будут созданы следующие файлы:
./testresults/cpuinfo.txt в него будет помещена информация о физическом процессоре, которую можно будет расшифровать на сайте вендора. Если эта информация не идет в разрез с информацией от провайдера, все в порядке.
./testresults/cpu_bench.txt результаты теста производительности процессора утилитой NBench



Тут нас интересует сумма этих трех значений. Чем она больше, тем лучше производительность
./testresults/steal.log ежесекундные результаты замера параметра steal time
./testresults/average-steal.log среднее значение steal time

Steal time это процент времени, в течение которого виртуальный процессор (vCPU) ожидает физический CPU, пока гипервизор обслуживает другой vCPU.
В случае когда виртуальная машина совместно использует ресурсы с другими экземплярами на одном хосте в виртуализированной среде, этот параметр определяет потерю времени за счет ожидания выполнения задач других виртуальных машин.
Steal time измеряется в процентах и указывает на то, что процессам внутри ВМ не хватает процессорного времени. Этот показатель напрямую влияет на производительность ваших приложений и по-хорошему должен быть равен нулю. Однако здесь есть нюанс: если провайдер пользуется ПО от VMware, виртуальная машина может показывать ноль из-за того, что гипервизор не отдает ей актуальные данные. Так что, если steal time отсутствует, а ВМ очевидно притормаживает, имеет смысл потребовать объяснений у провайдера. Возможна переподписка, по коням!

Далее обратимся к дискам. Помимо очевидного IOPS и Bandwidth, нас будет интересовать показатель времени отклика. Он отражает время, которое проходит с момента обращения к диску до того, как он начнет передавать данные. В нормальной ситуации должно проходить <5мс.

@vm1./perf.sh disk

Тестирование диска проводится при помощи утилиты fio. Эта утилита симулирует желаемую нагрузку операциями ввода\вывода. Существует несколько основных задаваемых параметров, о которых ниже:
1. I/O type (тип ввода\вывода)
Определяет основной алгоритм проверки. Последовательное или случайное чтение\запись или, возможно, даже смешанный режим. Буферизированный ввод-вывод или прямой (raw).
2.Block size (размер блока)
Очевидно, определяет размер блока (ов), используемого в тестах. Это может быть единственное значение или диапазон.
3. I/O size (размер ввода/вывода)
Определяет количество данных, используемых в тесте.
I/O engine (движок)
Определяет использование технологий, таких как: Memory mapping, splice, async I/O, SG.
I/O depth (глубина)
При использовании операций асинхронного ввода/вывода определяет количество потоков, которые используются в тесте.

После данного шага будут создан следующий файл:
./testresults/fio-results.txt данные о производительности дисков (input/output). Разумеется, чем быстрее, тем лучше, но стоит учесть, что если во время тестирования на ВМ проводились операции чтения/записи, эти показатели могут быть хуже, чем реальные.



Если по результатам этого теста какие-то параметры оказались хуже, чем вы ожидали, не спешите огорчаться. Есть автомобили гоночные, а есть грузовые. Болид Формулы легко обгонит тяжелую фуру, но при этом не сможет везти многотонный груз. Так что при оценке результатов исходите из своих задач и цифр, прописанных в SLA с провайдером.

Далее мы замеряем скорость обмена данными между виртуальными машинами. Здесь все точно так же, как и в случае с дисками: чем быстрее, тем лучше. Чтобы понять, насколько ваши параметры близки к нормальным, обратитесь к SLA. Оптимальные результаты выглядят следующим образом:

Скорость между BM (замеряем пропускную способность сети (gbit/sec)):

@vm1:     iperf3 -s -p 5201 @vm2:     iperf3 -c <vm1_ip> -p 5201 -t 300 -V

Тут необходимо обратить внимание на следующие показатели:
Bandwidth средняя скорость передачи данных за интервал времени. Чем выше этот показатель, тем больше пропускная способность сети
Retr количество повторно отправленных TCP-сегментов. Чем ниже этот показатель, тем лучше. В идеале он должен равняться нулю.

Разумеется, по итогам этих тестов вы не сможете со 100% гарантией утверждать, что переподписки у вашего провайдера нет совсем или что она душит ваше приложение. По-настоящему важно не то, что происходит на бэкграунде провайдера, а то, как фактически ведут себя ваши приложения в его инфраструктуре. Если вас все устраивает, запускать тесты и тратить уйму времени на сопоставление результатов будет странно. Если что-то не так замеряйте, ищите причины и разговаривайте с провайдером.

storage.cloud.croc.ru/c2-multimedia/habr_PR/ModifyIOPS_UI.gif

Практически любой бизнес сталкивается с плавающей нагрузкой: то тишина, то шквал. За примерами далеко ходить не надо:

• посещаемость интернет-магазина может значительно колебаться в зависимости от времени суток или сезона;
• внутренние сервисы компаний могут пустовать неделями, а накануне сдачи квартального отчета их посещаемость резко подскочит.

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

Пара слов о дисках

Все наши клиенты хотят плюс-минус одного получить надежную, соответствующую требованиям бизнес-процессов инфраструктуру по хорошей цене. Соответственно, перед нами как перед облачным провайдером стоит задача построить услуги и сервисы таким образом, чтобы для каждого клиента мы могли без труда подобрать оптимальное решение.
Ранее у нас было два уровня хранения данных: st2 и gp2. Цифра 2 в нашей внутренней терминологии означает более новую, улучшенную версию.

st2: Standard (HDD) неторопливые и недорогие носители на SAS HDD. Отлично подходят для сервисов, где IOPS не имеют решающего значения, но важна пропускная способность.
Параметры у них следующие: время отклика не более 10 мс, производительность дисков размером до 2000 ГБ 500 IOPS, от 2000 ГБ 1000 IOPS, а пропускная способность растет с каждым гигабайтом и доходит до 500 МБ/с на тех же 2000 ГБ.

gp2: Universal (SSD) более дорогие и быстрые накопители на SAS SSD. Подходят заказчикам, чьи приложения более требовательны к количеству операций ввода-вывода в секунду. Например базы данных интернет-магазинов.

Параметры gp2 указаны в SLA. Производительность в IOPS рассчитывается по объему на 1 ГБ приходится 10 IOPS. Верхняя планка 10000 IOPS. А время отклика таких дисков уже не более 2 мс. Это довольно высокая производительность, способная закрыть 97% бизнес-задач.

За годы работы мы накопили достаточно много статистики и экспертизы в отношении заказчиков и заметили, что некоторым из них не совсем комфортно выбирать из двух вариантов дисков. Например, кому-то требуется производительность повыше, чем 10 IOPS на гигабайт объема. Или плавающая нагрузка не дает возможность остановиться на одном из типов, а платить за готовые к часу пик, но периодически простаивающие мощности тоже не вариант.

Можно смоделировать простой злободневный кейс. В период пандемии одной компании потребовалось оформить пропуска для сотрудников. Чтобы они спокойно по Москве ездили. Штат большой, две тысячи человек. Вышел приказ срочно обновить личные данные в корпоративной CRM-системе. Сказано сделано. Больше тысячи человек одновременно бросились актуализировать информацию. Но CRM-кой занимались экономные люди. Мощностей выделили мало. Никто же не ожидал, что в нее больше десяти человек одновременно полезет! Все упало и еще сутки не могло подняться. Бизнес-процессы нарушились, люди сидят по домам и боятся штрафов. А если бы существовала возможность гибко подкрутить производительность дисков в облаке подняли бы IOPS ненадолго, а потом вернули, как было, исключив или значительно сократив время простоя CRM.

С одной стороны, ситуация гротескная, процент заказчиков с такими потребностями не очень велик. Маленький провайдер и вовсе принял бы их существование за статистическую аномалию и не предпринимал бы никаких действий. С другой организация нового уровня хранения позволит нам повысить гибкость услуг для всех клиентов. Значит, делать надо.

Если вы давно следите за нашим блогом, то наверняка помните статью, в которой мы рассказывали о череде экспериментов над Dell EMC ScaleIO (ныне PowerFlex OS) и его внедрении в Облако КРОК. Как бы то ни было, рекомендуем вам ознакомиться с ней для общего понимания.

В общих чертах скажем: ScaleIO (DellEMC переименовал ScaleIO сначала в VxFlex OS, а c 25 июня 2020 года в PowerFlex OS) супер универсальный и надежный Software-Defined Storage, SDS. У нас надежность это требование 0. Поэтому каждый узел, составляющий часть Storage Poolа установлен в отдельную стойку, что исключает возможность потери данных при частичной потере электропитания в ЦОД или локально в стойке.

Если из строя выйдет диск, сервер или целая стойка, у нас будет достаточно времени, чтобы отреплицировать данные на другие хосты и в последствии заменить сбойный элемент. Если умрут сразу две стойки, все равно ничего не потеряется. В этой ситуации кластер перейдет в аварийный режим, запись и чтение данных с дисков будет ограничено, но после восстановления связности с упавшей стойкой PowerFlex OS сам займется процессом Rebuildа данных и восстановления работы кластера. Такой процесс, кстати, чаще всего занимает не более пары минут.

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

С точки зрения универсальности PowerFlex OS (бывш. ScaleIO) также идеально подходит под наши требования. Фактически это конструктор, готовый к приему любых нагрузок и способный принимать и медленные SATA/SAS HDD диски, и быстрые SSD, и ультра-скоростные NVME накопители. И это действительно правда проверено на многочисленных stage- и testing-стендах команд разработки и эксплуатации, собрать кластер можно практически из говна и палок любого старого железа.

Музыка с пяти до шести

Давайте рассмотрим один из сценариев, в которых заказчику может потребоваться гибкая производительность, на реальном примере. Среди наших клиентов есть сеть магазинов музыкальных инструментов. Технические специалисты компании отслеживают, сколько посетителей посещают их сайт в каждый день и час. Это отражено даже в нашем SLA: с 17:00 до 18:00 магазин получает максимальное количество покупателей, поэтому никаких технических работ или простоев быть не должно.

Стандартная практика расчетов когда 100% нагрузки делятся 24 часа. Выходит примерно 4% на каждый час. У сети музыкальных магазинов этот конкретный час весит не 4, а 10% это десятки тысяч посетителей и покупателей.

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

Теперь у нас появилась возможность в самые нагруженные часы выдавать клиентам хоть 30, хоть 50 тысяч IOPS, а в остальное время держать производительность на обычном уровне. Такой тип хранения мы назвали io2: Ultimate (SSD). Время отклика дисков на основе этого типа хранения уже не более 1 мс!

И снова о надежности: st2, gp2 и новый io2 это самостоятельные, независимые друг от друга Storage Poolы в кластере PowerFlex.

Если раньше клиент выбирал диск и получал фиксированную производительность, то теперь он может ее, производительность, выбирать и настраивать. Вне зависимости от объема. Философия здесь следующая: получить огромный и быстрый диск можно у большого количества провайдеров, но готовы ли вы платить за него 100% времени?

Как управлять

Управлять производительностью можно двумя способами: по старинке, через веб-интерфейс, и с помощью API. Это дает возможность написать простые скрипты, которые по расписанию будут ускорять или замедлять диски и, соответственно, экономить ваши ресурсы.

Если раньше мы могли принять любую нагрузку, требующуюся клиенту, теперь мы можем сделать это по оптимальной цене.

Вот, как это выглядит на практике

Повышение адаптивности облачной инфраструктуры это актуальный и очень правильный тренд. Нельзя говорить заказчику: бери, что дают, а то и этого не будет!. Он должен иметь возможность решать, какие ресурсы, когда и в каком объеме ему требуются. Именно за такими гибкими и надежными решениями будущее.

За свои сервисы мы ручаемся: все параметры прописаны в SLA, и вы можете рассчитывать на то, что бумажные цифры с реальными не разойдутся.
А как проверить своего облачного провайдера, мы уже писали в предыдущей статье.

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

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

Миграция проходит по одному и тому же сценарию: компания проводит конкурс, выбирает провайдера по ассортименту сервисов, характеристикам и ценам, а затем начинает переезд. На этом этапе и происходят многие технические проблемы.

С чем приходится сталкиваться

Хорошо, если целевое облако использует ту же платформу виртуализации, что и исходное. Так, при миграции из VMware на VMware достаточно сделать снапшот и загрузить его в новое облако. Это просто и, как правило, перенос проходит без неожиданностей. Для самой системы не меняется ничего, кроме IP-адресов и железа, на котором работает виртуализация.
А вот при переходе с VMware на гипервизор KVM задача усложняется, ведь KVM использует другой формат виртуальных машин. Чтобы преодолеть несовместимость, необходимо сделать дамп дисков и провести конвертацию. Попутно придется записать в виртуалку драйвера, которые позволят запуститься на новом гипервизоре.

На самом деле, как показывает практика, эти трудности вполне можно преодолеть, но долгое время переезд с одного гипервизора на другой фактически означал большой объем работы для инженеров и головную боль для клиентов. Такую миграцию не выполнить за несколько дней, а если инфраструктура большая, можно провозиться и больше недели. Чтобы сохранить консистентность данных в таких условиях, приходится уходить на продолжительный даунтайм.
Это при том, что даже несколько дней без рабочей облачной инфраструктуры означают огромные денежные и репутационные потери. А даунтайм, который растянулся на неделю это не просто страшно звучит, это катастрофа для многих клиентов.

Поэтому в идеале миграция должна проходить как можно быстрее и, по возможности, без остановки сервисов. Для этого можно было использовать, например, Carbonite Migrate, но мы взвесили все за и против и нашли более подходящее решение для миграции из облака в облако Hystax Acura.

Как работает Hystax Acura: теория

Этот инструмент работает с VMware, KVM и Hyper-V, поддерживает перенос с физических серверов и при этом не дорог. Так что мы используем его для автоматической миграции в Облако КРОК, бекапов, резервирования и аварийного восстановления инфраструктуры заказчиков. Во всех этих случаях архитектура и принцип работы Hystax Acura одинаковы.
С одной стороны, у нас есть source-окружение, исходное облако или физический сервер, где запущена инфраструктура пользователя. С другой стороны находится Облако КРОК. И стоит задача перенести данные с source на target.

На стороне source-окружения устанавливается один из трех репликационных агентов.
Два из них предназначены для Linux или Windows соответственно. Они устанавливаются внутрь виртуальной машины и работают как сервисы на уровне операционной системы. Третий предназначен специально для миграции с VMware. Он развертывается на уровне ESXi-хоста и позволяет реплицировать сразу все находящиеся вокруг виртуальные машины.
Репликационные агенты отправляют данные на target-облако на уровне блоков. Причем репликация происходит в фоновом режиме, без необходимости останавливать виртуальные машины в source-облаке.

Ресивер-сервис Hystax Acura принимает данные и также поблочно записывает в их свежесозданный том в Облаке КРОК. По окончании репликации мы снимаем снапшот. Эти снимки образуют цепочку ресторпойнтов.Консистентность данных для Windows-машин обеспечивает стандартная служба VSS (Volume Shadow Copy Service). Для Linux-агента разработчики Hystax выпустили собственный проприетарный драйвер, который дублирует функциональность VSS. Что касается VMware там используется СBT API.
После создания снапшота остается лишь подать команду на запуск реплицированной виртуальной машины на новом месте.

Прямо перед поднятием машины на target-облаке Acura проводит автоматическое V2V-преобразование. Это одна из основных вещей, которые необходимо сделать, чтобы машина завелась при смене гипервизора.

Acura инжектит в виртуальную машину новые драйвера, вырезает старые, если это необходимо, и подстраивает bootloader, чтобы виртуальная машина запустилась на КVM.
Длительность этого процесса зависит от размера машины. V2V-преобразование занимает считаные минуты и идет параллельно, если одновременно поднимается несколько виртуальных машин.

Запуск группы виртуальных машин осуществляется по заранее составленному DR-плану. Он включает в себя описание виртуалок, настройки сетей, и оркестрацию задание правильного порядка запуска взаимозависимых сервисов.

Ограничения Hystax Acura

Такой подход позволяет мигрировать в Облако КРОК практически с любой технологии, но у Hystax Acura есть и ограничения.

Так, в случае Linux работоспособность репликации и P2V/V2V преобразования зависит от версии ядра.

Выбор достаточно широк, но если нужного ядра не оказалось в списке поддерживаемых, придется подождать, пока Hystax не подготовит драйвера на заказ. Кроме того, репликационные агенты пока не умеют переносить Windows-системы, целиком развернутые на динамических дисках.

Миграция с Hystax Acura на практике

Hystax Acura делает процесс миграции в новое облако заметно легче. Настолько, что некоторые облачные провайдеры предлагают клиентам переехать к ним самостоятельно.
В принципе, графический интерфейс этого решения достаточно прост, чтобы разобраться без особой подготовки, но мы все равно все делаем сами и, как правило, через API. Мы заранее разрабатываем миграционный или DR-план, разворачиваем репликационных агентов, проводим тестовые миграции.

Конечно, мгновенных переездов не бывает, но теперь узким местом является не работа по портированию виртуальных машин с одного гипервизора на другой, которая занимает непредсказуемо много времени, а пропускная способность сети.
Больше всего времени уходит на передачу данных при первой репликации, но это предсказуемый процесс, и необходимое время рассчитывается при помощи простого калькулятора.

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

При следующих, инкрементальных репликациях Acura отсылает только дельты, изменения на виртуальных машинах, и репликация проходит намного быстрее. Поэтому RTO (recovery time objective), время, которое система будет недоступна во время переезда, фактически равняется скорости загрузки машин на target-стороне.



Скриншот DR-плана (json)
Перед окончательным переездом мы проводим тестовый запуск и замеряем, сколько времени нужно на загрузку. Так мы определяем, на какое время необходимо остановить сервисы на source-стороне, чтобы не потерять ни байта данных. Около десяти минут даунтайма, и гигантская инфраструктура готова принимать трафик в нашем облаке.

Что касается аварийного восстановления, то, по нашим подсчетам, RPO (recovery point objective время, за которое можно потерять данные), составляет три минуты для виртуалок на Linux и пять минут для Windows. Это впечатляющие показатели, и теперь вы знаете, какие технические решения позволяют добиться их на практике.

Если у вас остались вопросы по работе Hystax Acura и Облака КРОК в целом, не стесняйтесь оставлять их в комментариях или присылайте на почту: RSayfutdinov@croc.ru

На эту тему мы провели вместе с Dell Technologies и AMD онлайн-митап 29 октября, который в общей сложности увидело более 150 ИТ-разработчиков начинающих и не очень.

Ниже запись мероприятия на случай, если вы хотели присоедениться и посмотреть, но не смогли.

Популярность микросервисной инфраструктуры растет: все больше компаний переходят на нее, чтобы удобнее и быстрее разрабатывать приложения и новые клиентские сервисы в контейнерах. Но не у всех клиентов этот переход осуществляется гладко.

• Запуск с нуля контейнерной среды оказался сложным и трудозатратным?
• Не хватает DevOps-инженеров?
• Нет понятных инструкций, как разграничить ответственность между Dev и Ops
• Затраты на инфраструктуру увеличиваются непрогнозированно и непропорционально запуску новых кластеров?
• Вы чувствуете давление бизнес-заказчиков внутри компании, которые требуют выпускать продукты точно в срок?

На примере кейсов для банка, ритейлера и туристической компании рассказали, как упростить переход на микросервисную архитектуру с использованием готовых кластеров Kubernetes и сократить затраты на базовые сервисы при общем повышении эффективности разработки.

В программе:

• Сценарии применения Kubernetes as a service: когда это действительно необходимо
• Экономика DevOps: дешевле ли вырастить компетенцию внутри?
• Выстраивание зон ответственности между провайдером и пользователем K8s-кластера
• Лайфхак: как быстрее пройти согласование службой информационной безопасности при внедрении инфраструктуры кластера Kubernetes на примере кейса с Банком
• Как сэкономить на инфраструктуре с помощью процессоров AMD на базе серверов Dell Technologies