Балансировка нагрузки 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 #виртуализация #схд

Инфраструктура как код и управление IT-ресурсами


В современном мире, где технологические изменения происходят с бурной скоростью, прогрессивные организации стремятся к более гибкому, автоматизированному и масштабируемому управлению своей инфраструктурой. Инфраструктура как код (Infrastructure as Code, IaC) становится ключевым элементом этой эволюции, обеспечивая более эффективное управление IT-ресурсами и привнося инновации в область технологического управления.

От ручных действий к автоматизации

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

Преимущества инфраструктуры как код

•Гибкость и масштабируемость: IaC позволяет быстро адаптироваться к изменяющимся требованиям, автоматически масштабировать ресурсы и реагировать на нагрузочные всплески.
•Однородность в коде: Использование кода для определения инфраструктуры обеспечивает единообразие и консистентность в развертывании, что снижает вероятность ошибок и облегчает сопровождение.
•Версионирование и возможность отката к стабильной версии: IaC поддерживает версионирование кода, позволяя отслеживать изменения и в случае необходимости быстро возвращаться к предыдущим версиям.
•Быстрое развертывание и доставка: Автоматизированное развертывание позволяет сократить время от идеи до продуктивной среды, поддерживая концепцию Continuous Delivery.
•Командный труд: IaC способствует совместной работе разработчиков, системных администраторов и других участников команды.

Использование IaC на практике

•Декларативный подход: IaC часто использует декларативный подход, где описывается желаемое состояние системы, и инструмент самостоятельно выстраивает инфраструктуру в соответствии с этим описанием.
•Инструменты IaC: Несколько популярных инструментов IaC включают Terraform, AWS CloudFormation, Ansible. Эти инструменты предоставляют разные уровни абстракции и гибкости в описании инфраструктуры.
•Развитие DevOps-Практик: IaC тесно связан с DevOps-подходом, обеспечивая интеграцию между разработкой и операционной деятельностью для улучшения производительности и стабильности системы.

Вызовы и Решения

•Обучение и Переосмысление Процессов: Внедрение IaC требует новых навыков и пересмотра процессов развертывания и управления.
•Безопасность: Необходимо уделить внимание обеспечению безопасности кода инфраструктуры, чтобы предотвратить уязвимости.
•Сложность Кода: С ростом инфраструктуры может возникнуть сложность в поддержке кода. Внимательное проектирование и структурирование могут снизить этот риск.

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

#engineering #iac #devops #cloudlink #cloud