👋🏼 С пятницей всех! Впереди выходные, а значит будет время подумать о горячей теме – миграции с VMware на zVirt. Насколько это больно? 😉

Сейчас процесс миграции такой (на примере одного крупного заказчика):

👉🏼 17 операций (из них 3 ручные)
👉🏼 Миграция 1 ВМ занимает десятки минут
👉🏼 По 1 ВМ за раз (по очереди)
👉🏼 Примерно 50 ВМ в месяц

А вот так будет в Q4 после внедрения автомиграции (v2v-миграции):

🤩 Всего 2 клика
🤩 Миграция 1 ВМ занимает десятки секунд
🤩 Несколько ВМ параллельно
🤩 Примерно 300 ВМ в месяц

Ждать уже недолго!

#zVirt #новости_продуктов

Балансировка нагрузки 1/7

В этой серии постов поговорим про уровни и типы балансировки, их основные алгоритмы и методы. Сегодня напомним уровни балансировки в целом и про балансировку на сетевом уровне в частности.

Зачем нужна?

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

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

Основные цели:
• Распределение нагрузки между серверами
• Повышение отказоустойчивости
• Защита от некоторых видов атак


Уровни балансировки

Балансировка нагрузки осуществляется при помощи аппаратных и программных инструментов, т.е. целого комплекса алгоритмов и методов, соответствующим уровням модели OSI:

• сетевой уровень
• транспортный уровень
• прикладной уровень

Расскажем обо всем по порядку

Балансировка на сетевом уровне

Чтобы сделать балансировку на сетевом уровне, нужно сделать так, чтобы на один IP-адрес сервера (destination IP) отвечали разные машины. Такая балансировка может осуществляться несколькими способами:

• DNS-балансировка. На одно доменное имя выделяется несколько IP-адресов. Сервер, на который будет направлен клиентский запрос, обычно определяется с помощью алгоритма Round Robin
• Построение NLB-кластера. При использовании этого способа серверы объединяются в кластер, состоящий из входных и вычислительных узлов. Распределение нагрузки осуществляется при помощи специального алгоритма
• Балансировка по IP с использованием дополнительного маршрутизатора.
• Балансировка по территориальному признаку осуществляется путём размещения одинаковых сервисов с одними и теми же адресами в территориально разных регионах размещения (например, Anyсast DNS и в различных CDN).

Плюс такого метода:
• Независимость от протоколов высокого уровня
• Один публичный адрес
• Полная прозрачность работы для серверов

Недостатки:
• Повышенная нагрузка на балансировщик за счет обратного графика

#балансировка_нагрузки #модель_osi #engineering #dns

Балансировка нагрузки 2/7

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

Балансировка на транспортном уровне (ECMP)

Клиент обращается к балансировщику, тот перенаправляет запрос одному из серверов, который будет его обрабатывать. Выбор сервера, на котором будет обрабатываться запрос, может осуществляться в соответствии с самыми разными алгоритмами: путём кругового перебора, путём выбора наименее загруженного сервера из пула и т.д.

Зачастую балансировку на транспортном уровне не отличить от балансировки на сетевом уровне. Рассмотрим следующее правило для сетевого Packet Filter в OpenBSD: тут идет речь про балансировку трафика на конкретном 80-ом порту TCP:

web_servers = "{ 3.3.3.1, 3.3.3.2, 3.3.3.3 }"

match in on $ext_if proto tcp to port 80 rdr-to $web_servers round-robin sticky-address

Рассмотрим теперь другой пример:

pass in on $int_if from $lan_net \
route-to { ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) }\
round-robin

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

В чем различие?

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

На транспортном уровне общение с клиентом замыкается на балансировщике, который работает как прокси. Он взаимодействует с серверами от своего имени, передавая информацию о клиенте в дополнительных данных и заголовках. Таким образом работает небезызвестный программный балансировщик HAProxy.

Плюсы
• Все также не зависит от протоколов высокого уровня
• Все также один публичный адрес

Минусы

• Надо устанавливать на серверы дополнительный софт, чтобы анонсировать серверную сеть на роутер
• Ограниченное количество ECMP на роутер (от 8 до 32 маршрутов, в зависимости от роутера)
• При такой схеме нагрузка на все серверы распределяется равномерно, что накладывает требование одинаковости на все серверы. И если добавлять в кластер более современный, мощный, сервер, нагрузка на него будет не больше, чем на соседа.

#балансировка_нагрузки #транспортный_уровень #ecmp #engineering

Балансировка нагрузки 3/7

Балансировка на прикладном уровне

На этом уровне балансировщик работает в режиме «умного прокси», он анализирует клиентские запросы и перенаправляет их на разные серверы в зависимости от характера запрашиваемого контента. Так работает, например, Nginx, распределяя запросы между фронтендом и бэкендом. За балансировку в Nginx отвечает модуль Upstream.

Nginx. Установка и дополнительные способы эффективного распределения нагрузки

Nginx можно быстро установить с помощью apt-get (при наличии соответствующих привелегий, естественно):

sudo apt-get install nginx

Для настройки round robin нам потребуется использовать модуль upstream. Включим конфигурацию в настройки nginx, например:

sudo nano /etc/nginx/sites-available/default

Добавляем файл конфигурации

upstream backend { server backend1.example.ru; server backend2.example.ru; server backend3.example.ru; }

Ссылаемся на этот модуль:

server { location / { proxy_pass http://backend; } }

Перезапускам nginx:

sudo service nginx restart

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

Выглядит хорошо, но можно лучше.

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

Настройка балансировки нагрузки с учетом веса сервера может выглядеть следующим образом:

upstream backend { server backend1.example.ru weight=1; server backend2.example.ru weight=2; server backend3.example.ru weight=4; }

По умолчанию вес равен 1. При весе 2 на backend2.example будет отправляться в два раза больше трафика, чем на backend1, а backend3 с весом 4 будет обрабатывать в два раза больше трафика, чем backend2, и в четыре раза больше, чем backend1.

IP-хэш позволяет серверам отвечать клиентам в соответствии с их IP-адресом, отсылая посетителей к одному и тому же VPS при каждом посещении (если только этот сервер не отключен). Если известно, что сервер не работает, он должен быть помечен как неработающий. При этом все IP-адреса, которые должны были направляться на неработающий сервер, перенаправляются на другой:

upstream backend { ip_hash; server backend1.example.ru; server backend2.example.ru; server backend3.example.ru down; }

По умолчанию nginx будет отправлять данные на серверы, даже если они не отвечают. Max fails позволяет автоматически предотвратить это, переводя не отвечающие серверы в нерабочее состояние на заданный промежуток времени.

С max fails связаны два фактора: max_fails и fall_timeout.
Max fails означает максимальное количество неудачных попыток подключения к серверу, которое должно произойти, прежде чем он будет признан неактивным.
Fall_timeout определяет время, в течение которого сервер считается неработоспособным. По истечении этого времени новые попытки связаться с сервером начнутся снова, по умолчанию 10 секунд.

upstream backend { server backend1.example.ru max_fails=3 fail_timeout=15s; server backend2.example.ru weight=2; server backend3.example.ru weight=4;

Что есть еще?

В качестве ещё одного примера инструмента балансировки на прикладном уровне можно привести pgpool — промежуточный слой между клиентом и сервером СУБД PostgreSQL. С его помощью можно распределять запросы серверам баз данных в зависимости от их содержания, например, запросы на чтение будут передаваться на один сервер, а запросы на запись — на другой.

Установив Cloudlink в периметре своей организации вы можете за 5 минут в несколько кликов получить сервер с предустановленным Nginx и PostreSQL любой версии и любой конфигурации, в том числе отказоустойчивый геораспределенный кластер СУБД👏🏻
Забудьте про потенциальные ошибки при ручном конфигурировании, доверьте свою инфраструктуру умной автоматизации Cloudlink 👍🏻

Записывайтесь на демо в комментариях

#engineering #прикладная_балансировка #nginx

Балансировка нагрузки 4/7

Принципы выбора алгоритма и метода балансировки

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

Среди целей и свойств следует выделить следующие:

• справедливость: гарантировать, что на обработку каждого запроса выделяются системные ресурсы и не допускать возникновения ситуаций, когда один запрос обрабатывается, а все остальные ждут своей очереди
• эффективность или равномерная загрузка ресурсов системы: все серверы, обрабатывающие запросы, должны быть заняты на 100%. Нельзя допускать ситуации, когда один из серверов простаивает в ожидании запросов на обработку (к слову, в реальности это практически недостижимо, но к этому нужно стремиться)
• сокращение времени выполнения запроса: следует обеспечить минимальное время между началом обработки запроса и его завершения
• сокращение времени отклика: нужно минимизировать время ответа на запрос пользователя
• предсказуемость: понимать при каких ситуациях и нагрузках алгоритм будет эффективным
• масштабирумость: алгоритм должен сохранять работоспособность при увеличении нагрузки.
#load_balancer #балансировка

Балансировка нагрузки 5/7

Round Robin

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

Самой распространёной имплементацией этого алгоритма является Round Robin DNS. Любой DNS-сервер хранит пару «имя хоста — IP-адрес» для каждой машины в определённом домене. С каждым именем из списка можно ассоциировать несколько IP-адресов. Выглядит это примерно так:

www.example.ru 1.1.1.1
www.example.ru 2.2.2.2
www.example.ru 3.3.3.3
www.example.ru 4.4.4.4


DNS-сервер проходит по всем записям таблицы и отдаёт на каждый новый запрос следующий IP-адрес: например, на первый запрос — 1.1.1.1, на второй — 2.2.2.2, и так далее. В результате все серверы в кластере получают одинаковое количество запросов.

Плюсы:
• Независимость от протоколов высокого уровня. Round Robin использует любой протокол, в котором обращение к серверу идёт по имени
• Не зависит от нагрузки на сервер. Кэширующие DNS-серверы помогут справиться с любым наплывом клиентов.
• Не требует связи между серверами. Можно использовать для локальной и для глобальной балансировки
• Практически нулевая стоимость. Достаточно добавить несколько записей в DNS.

Минусы:
• При выполнении всех операций должно быть задействовано одинаковое количество ресурсов. В реальности эти условия в большинстве случаев невыполнимы.
• Не учитывается количество активных подключений на данный момент времени
• Не учитывает загруженность серверов в кластере. Если один из серверов загружен на 100%, а другие на 10-15%, то по умолчанию загруженный сервер будет получать столько же запросов сколько и остальные


Weighted Round Robin

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

#engineering #dns #round_robin #балансировка_нагрузки

Балансировка нагрузки 6/7

Leastconn

Допустим есть два сервера: к server1 подключено меньше пользователей, чем к server2, но первый оказывается более перегруженным. Это происходит из-за того, что к server1 подключения поддерживаются дольше, чем к server2.

Такая проблема решается с помощью алгоритма least connections, который учитывает количество подключений, поддерживаемых серверами в текущий момент времени и каждый следующий вопрос передаётся серверу с наименьшим количеством активных подключений.

Как и во всех предыдущих примерах, есть усовершенствованная версия этого алгоритма — Weighted Least Connections — которая делает то же самое + учитывает весовой коэффициент серверов.

Locality-Based Least Connection Scheduling

Этот метод создан для кэширующих прокси-серверов: наибольшее количество запросов передаётся серверам с наименьшим количеством активных подключений. За каждым из клиентских серверов закрепляется группа клиентских IP. Запросы с этих IP направляются на «родной» сервер, если он не загружен полностью. Если загружен, то запрос уйдет на другой, менее чем на половину загруженный сервер.

Locality-Based Least Connection Scheduling with Replication Scheduling

В этом алгоритме каждый IP-адрес или группа IP-адресов закрепляется за целой группой серверов. Запрос передаётся наименее загруженному серверу из группы. Если же все серверы из «родной» группы перегружены, то будет зарезервирован новый сервер. Этот новый сервер будет добавлен к группе, обслуживающей IP, с которого был отправлен запрос. Чтобы избежать избыточной репликации, наиболее загруженный сервер из этой группы будет удалён


#балансировка_нагрузки #engineering

Балансировка нагрузки 7/7

Destination Hash Scheduling и Source Hash Scheduling

Destination Hash Scheduling был создан для работы с кластером кэширующих прокси-серверов. В этом алгоритме сервер, обрабатывающий запрос, выбирается из статической таблицы по IP-адресу получателя.

Source Hash Scheduling основывается на тех же самых принципах, только сервер, который будет обрабатывать запрос, выбирается из таблицы по IP-адресу отправителя.

Липкие сессии (Sticky Sessions)

Sticky Sessions — алгоритм распределения входящих запросов, при котором соединения передаются на один и тот же сервер группы. Сессии пользователя могут быть закреплены за конкретным сервером с помощью метода IP hash. С помощью этого метода запросы распределяются по серверам на основе IP-aдреса клиента. Метод гарантирует, что запросы одного и того же клиента будет передаваться на один и тот же сервер. Если закреплённый за конкретным адресом сервер недоступен, запрос будет перенаправлен на другой сервер.

Пример фрагмента конфигурационного файла:

upstream backend {
ip_hash;

server backend1.example.ru;
server backend2.example.ru;
server backend3.example.ru;
server backend4.example.ru;
}


Если клиент использует динамический IP, то могут возникнуть проблемы с привязкой сессий. В ситуации, когда большое количество запросов проходит через один прокси-сервер, балансировку вряд ли можно назвать эффективной и справедливой. Но это можно решить, используя cookies.
В коммерческой версии Nginx имеется специальный модуль sticky, который как раз использует cookies для балансировки. Есть у него и бесплатные аналоги — например, nginx-sticky-module.
Метод sticky-sessions можно также использовать в HAProxy.

#nginx #балансировка_нагрузки #haproxy

Всех с пятницей, коллеги!

Не забываем отметить прошедший день программиста (если вдруг не успели)

Очереной оффтоп пост от наших партнеров @orionsoftru Orionsoft про ProximaDB — российская система управления базами данных на базе PostgreSQL 🔥

ProximaDB идеально подходит для Вас, если стоят задачи:
• Миграции SAP на 1С
• Миграции СУБД MS SQL или Oracle на PostgreSQL
• Решение проблем с техподдержкой на зарубежные СУБД
• Выполнение требований регуляторов по импортозамещению

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

Выбор платформы виртуализации.
VMware vs OpenStack и немного про zVirt

VMware, zVirt и OpenStack – это востребованные и функциональные решения для построения и поддержки облачных инфраструктур
Сегодня мы сравним несравнимое технические характеристики VMware и OpenStack, а также поговорим про технологическую независимость

Хранение данных
Коробочные решения обычно предлагают аппаратные системы хранения данных. Для VMware это: NetApp, Dell, HPE, Hitachi и другие. 

Для OpenStack помимо тех же вариантов, можно организовать работу хранилища на базе Ceph, которое позволит создать объектное или блочное хранилище или, например, кластерную файловую систему в зависимости от ваших инфраструктурных потребностей
 
Гипервизоры

Гипервизором для VMware выступает встроенный ESXi, эмулирующий физические аппаратные ресурсы, который гарантирует безопасность при выполнении автоматизированных действий, обеспечивает изоляцию ресурсов ВМ и отслеживает автономность работы ОС в системе виртуализации.
 
В OpenStack предусмотрены различные варианты виртуализации – от того же ESXi или популярного Qemu до более сложного, но также востребованного среди продвинутых разработчиков – KVM, которое поддерживает работу со всеми основными дистрибутивами Linux, а это минимум 26 готовых образов.

Интерфейс

Для управления виртуальными машинами в VMware используется платформа vCloud Director, позволяющая создавать собственные ВМ, организовывать их в сети, настраивать NAT и firewalls.
 
Интерфейс OpenStack API считается уже вполне стандартным, но он может быть дополнен десятками доступных модулей, выполняющих отдельные задачи. Есть мнение, что интерфейс OpenStack достаточно сложен для восприятия конечными пользователями.

С пользовательской точки зрения

Потребителям облака в подавляющем большинстве случаев не принципиально на базе какой платформы разворачивается облачная инфраструктура. Главное, чтобы она была быстрой, удобной в использовании и надежна.
 
В условиях ухода с российского рынка многих зарубежных вендоров, важно понимать, что готовые решения вроде VMware находятся в зоне риска – провайдеры в любой момент могут быть отключены от работы с платформой по решению ее руководства, что в лучшем случае приведет вас к простоям в работе и потере прибыли, а в худшем – полностью парализует работу вашей IT-инфраструктуры, в то время такие open-source решения как OpenStack или разработки российских поставщиков услуг ИТ-инфраструктуры как zVirt, гарантируют полную надежность в этом плане.

Вывод
 
На сегодняшний день в России безопаснее использовать российские разработки и/или opensource решения, чтобы митигировать риски внезапного отключения или объявлений о скором уходе с российского рынка.
Созвездие продуктов Orionsoft @orionsoftru имеет достаточно инструментов для того, чтобы ваша компания могла заниматься бизнесом, возложив задачи по сопровождению ИТ-инфраструктуры на опытные команды сопровождения и разработки.
 
Cloudlink работает со всеми вышеупомянутыми платформами виртуализации и может помочь обеспечить бесшовный переходный период миграции информационных и автоматизированных систем в вашей организации.
Попробуйте Cloudlink в связке с этими продуктами, если еще нет 🙂

#vmware #openstack #zvirt #cloudlink #виртуализация #схд