что такое кластер в it сфере
Кластерные системы
Parking.ru как облачный провайдер имеет опыт оказания не только услуг с «обычной» надежностью, но и услуг хостинга высокой доступности, построенных на кластеризованной дублированной инфраструктуре.
Имея весомый опыт в построении таких инфраструктурных проектов, мы решили предложить его не только избранным клиентам (которые уже много лет используют эти услуги), а сделать стандартизированное предложение для всех желающих.
Parking.ru запустил целый ряд кластерных решений построенных на надежной дублированной инфраструктуре и имеющих в основе самые разные решения: от виртуальных машин до группы физических серверов. Отдельного внимания заслуживает предложение по ГЕО кластеризации в двух разных ЦОД, объединенных дублированными каналами связи.
Если рассматривать вкратце, то в рамках предложения существуют следующие типовые схемы кластеров:
Кластеры высокой доступности (High Availability cluster)
Создаются для обеспечения высокой доступности сервиса, предоставляемого кластером. Избыточное число узлов, входящих в кластер, гарантирует предоставление сервиса в случае отказа одного или нескольких серверов. Минимальное количество узлов — два, но может быть и больше.
Обычно High Availability кластер строится для Microsoft SQL server’ов, который поддерживает базы данных интернет проектов. High Availability кластер возможно построить и для Exchange систем.
Существует ещё одна разновидность High Availability SQL кластера — «зеркалирование БД» или database mirroring. Этот вид кластера не требует выделенного дискового хранилища, но для автоматического переключения в случае аварии нужен ещё один SQL сервер — следящий/witness. Такой кластер идеально подходит для WEB приложений и требует меньше затрат на создание.
Балансировка нагрузки (Network Load Balancing, NLB)
Принцип действия NLB-кластеров — распределение приходящих запросов на несколько физических или виртуальных узлов серверов. Первоначальная цель такого кластера — производительность, однако, они используются также для повышения надёжности, поскольку выход из строя одного узла приведет просто к равномерному увеличению загрузки остальных узлов. Совокупность узлов кластера часто называют кластерной фермой. Минимальное количество узлов в ферме — два. Максимальное — 32.
При размещении высоконагруженных web-проектов в режиме NLB строится ферма web-серверов на IIS 7.х
Кластеры на виртуальных машинах
Наиболее доступным и масштабируемым решением является построение кластера на основе виртуальных машин на платформе Hyper-V.
В качестве web-боксов NLB-кластера используются виртуальные машины с установленными на них Windows Web Server 2008 (IIS7.х, пользовательское приложение).
В качестве кластера баз данных используется две виртуальные машины необходимой мощности на Windows Server 2008 Standard Edition и SQL Server 2008 Standard Edition.
Отказоустойчивое единое хранилище данных на основе Storage System от NetApp или HP.
Для обеспечения бОльшей надежности все узлы кластера располагаются на различных физических серверах\узлах кластера.
Масштабируемость решения достигается путем увеличения мощности используемых виртуальных машин (вплоть до 100% мощности физического сервера), а также за счет добавления новых узлов в NLB-кластер.
С использованием средств онлайновой миграции со временем возможен перенос узлов кластера на новые, более современные физические сервера без потери работоспособности и без простоя любого узла.
Данный кластер является лучшим решением в соотношении цена/качество и рекомендуется как для критичных для бизнеса приложений, так и для относительно нагруженных web-проектов (
до 30000-50000 посетителей ежедневно).
Кластеры на физических серверах
Web-проекты с нагрузкой выше 50000 посетителей, проекты со специальными требования по безопасности требуют построения кластерных решений на выделенных серверах без потерь мощностей физических серверов на виртуализацию.
Схема построения таких кластеров аналогична схеме построения кластеров на виртуальных машинах, только в качестве узлов используются выделенные физические серверы.
Геокластеры
При построении локальных кластеров единой точкой отказа системы является сама инфраструктура ЦОД. Parking.ru предлагает уникальное решение на российском рынке — построение географически распределенного кластера, узлы которого располагаются в разных ЦОДах Parking.ru.
Каждый из узлов кластера имеет независимый выход в интернет, но при этом из сети данных кластер выглядят как единый сервер с единым адресом и контентом.
Технологии кластеризации — повышаем надежность и производительность веб-проекта
Добрый день, коллеги!
Сегодня хочу рассказать о технологиях кластеризации, которые появились в 10-й версии платформы 1С-Битрикс. Также разберем, какие важные задачи они позволят решить Вам, как руководителю веб-проекта и как эффективно использовать данные технологии, если Вы — разработчик. В конце статьи рассмотрим конкретные архитектуры работающих веб-кластеров на платформе 1С-Битрикс, в т.ч. ресурса www.1c-bitrix.ru.
Но прежде — постараемся объективно ответить на вопрос — в каких случаях все же целесообразно для реализации веб-проекта выбирать фреймворк или коробочное решение, а в каких — создавать веб-проект «с нуля».
Разработка веб-проекта «с нуля»
А при значительном увеличении посещаемости веб-ресурса, например, до миллионов хитов в сутки, может оказаться — что веб-решение вообще не создавалось для подобных нагрузок и должно быть «срочно» переписано заново.
Разработка веб-проекта на базе фреймворка
Расширение возможностей — благословение или проклятье?
Одной из краеугольной характеристик качественного фреймворка — это предоставление возможности, путем создания несложных надстроек, реализовать разные сценарии его использования. Например, а смогу я встроить нестандартный алгоритм расчета скидок в интернет-магазине без затратного переписывания ядра фреймворка высококвалифицированными программистами с опытом разработки н фреймворке от 5 лет :-)? А смогу я использовать разные валюты, курсы которых зависят от региона? А можно использовать внешнюю базу учетных записей из имеющейся системы для авторизации на веб-проекте?
В BitrixFramework, благодаря обязательной фазе углубленной системной аналитики проблемной области при разработке ядра и модулей платформы, реализованы основные распространенные бизнес-процессы, которые могут потребоваться в 95% веб-проектов. Для создания надстроек Вы всегда сможете задействовать механизм несложных обработчиков событий, с помощью которого можно реализовать практически любой фантастический сценарий бизнес-процесса программистом начальной или средней квалификации.
Тем не менее, иногда все же может оказаться, что задачу на фреймворке реализовать сложнее и дольше, чем написать «с нуля», и Вы об этом узнаете уже в процессе разработки :-). В этом случае фреймворки, как правило, предоставляют возможность модульного расширения. В BitrixFramework вам нужно будет создать модуль, реализующий нестандартную логику. Писать модуль обычно дольше, чем создавать обработчик события, но при этом достигается максимальная гибкость. Написать модуль относительно просто, но возможно такой модуль уже написан — поэтому стоит предварительно «порыться» в marketplace.
Разработка веб-проекта на базе коробочного решения
Данный подход скорее всего максимально сократит время и риски разработки веб-проекта, если ваши требования «близки» к функционалу коробки. Например, для создания и запуска типичного интернет-магазина с мультивалютным каталогом, авторизацией, скидками, персональным разделом, поиском и поддержкой многочисленных платежных систем скорее всего подойдет коробочное решение «1С-Битрикс: Управление сайтом» (редакция «Малый бизнес»).
Дополнительно, коробочное решение, являясь как бы «историей успеха» и «книгой рецептов», помогает Вам, как заказчику проекта, «пощупать» практические примеры реализации бизнес-задач. А разработчикам коробка позволяет изучить «исходники» решения, чтобы продублировать его, либо сделать лучше :-). Частый кейс при использовании коробки: «Сделайте также как тут и тут, чтобы в админке управлялось аналогично как там».
«Правильная» коробка не навязывает свои решения как истину в последней инстанции, позволяя «срезать» слой работающей реализации и заменить его на свою реализацию, базирующуюся на фреймворке. В 1С-Битрикс вы можете легко деинсталлировать из системы готовое решение, поставить новое для экспериментов, в том числе из Marketplace и выбрать свой, наиболее оптимальный путь.
Для каких типов веб-проектов окажутся полезными технологии кластеризации платформы 1С-Битрикс?
1) Вертикальный шардинг (вынесение модулей системы на отдельные серверы MySQL). Теперь можно вынести интенсивно используемые модули «Поиск» и «Веб-аналитика» на собственное «железо».
2) Репликация MySQL и балансирование нагрузки между серверами. Теперь можно распределить нагрузку на СУБД веб-проекта на группу серверов, добавляя их при необходимости. Технические подробности можно почитать тут.
3) Распределенный кеш данных (memcached). Надежное и масштабируемое кэширование критически важно для высоконагруженных проектов. Технические подробности тут.
4) Кластеризация сессий между веб-серверами. Эта необходимо при работе группы веб-серверов за балансировщиком. Почему мы храним сессии не в memcached — об этом напишем отдельно :-).
5) Кластеризация файлов веб-серверов. Это необходимо для автоматической синхронизации контента между машинами. Технические подробности тут.
Особое внимание хочется обратить на то, что технологии кластеризации используются на уровне ядра платформы 1С-Битрикс и дорабатывать код веб-проекта — не нужно! (каждый раз когда пишу про это, не верю, но… это так и есть на самом деле) Разумеется, при необходимости можно в коде задавать, с каких именно серверов репликации осуществлять чтение/запись — но это необходимо подавляющему меньшинству веб-проектов.
Также, если Вы разрабатываете веб-проект, которому возможно понадобятся технологии кластеризации в будущем — можно в принципе их «подключить» потом, когда в них возникнет необходимость, без доработки кода веб-проекта. Это серьезно удешевляет разработку веб-проекта, т.к. если сразу создавать систему под высокую нагрузку, работающую на 5 базах данных, с кластерной файловой системой и горизонтальным шардингом — то в случае ее невостребованности — вы напрасно потратите время и деньги.
Кластерные архитектуры работающих веб-проектов на базе 1С-Битрикс
Самый интересный раздел статьи — рассмотрим, наконец, конкретные примеры действующих веб-кластеров на платформе 1С-Битрикс.
www.kupibonus.ru — бесперебойная доставка услуг
Внедрение веб-кластера провел наш сертифицированный партнер «Linemedia», г. Москва. Редакция платформы – «Бизнес веб-кластер».
Веб-проект ежедневно посещают несколько сотен тысяч пользователей, также дополнительную нагрузку генерируют партнёры проекта, имеющие доступ к проекту через API Kupibonus. Активная двухсторонняя интеграция с бэк-офисом «1С: Предприятие», интенсивные каналы взаимодействия с внешними сервисами.
За счет внедрения веб-кластера обеспечена высокая производительность и отказоустойчивость не только публично части, но и внутренних бизнес-процессов и API. Внедрение прошло в довольно короткие сроки – две недели.
www.komos.ru — электронная биржа
Внедрение веб-кластера провел золотой сертифицированный партнер «Профессиональные Интернет-решения», г. Ижевск. Редакция платформы – «Веб-кластер».
Веб-проект является высоконагруженной площадкой для проведения электронных торгов группой компаний — «КОМОС ГРУПП». В состав группы входит 13 крупнейших предприятий, производящих продукты питания в Удмуртии и Пермском крае. Полученная в результате торгов стоимость предложений составила почти 5 млрд. рублей менее чем за год. За счет внедрения веб-кластера обеспечена высокая производительность и отказоустойчивость, легкая масштабируемость электронной торговой площадки.
www.1c-bitrix.ru — это мы
Веб-кластер размещен на группе EBS/EC2 машин в облаке Amazon. Достаточно большой объем статического контента. Высокая нагрузка как на публичную часть, так и на интеграционное API (marketplace), а также систему обновлений. За счет перехода на веб-кластер обеспечена высокая производительность и устойчивость, быстрое масштабирование в случае необходимости.
Мы хотели использовать встроенный в облако балансировщик, но пока, по причине его «негибкости», используем для этого отдельную машину. Бэкапы делаем в S3 встроенной в облако удобной технологией снепшотов, для резервного копирования raid10 на базе EBS разместили на нем XFS и, для целостного снепшота, «фризим» ее используя утилиту ec2-consistent-snapshot. Статику постепенно выносим в облако и CDN. Большинство рутинных операций: поднять машину в случае нагрузки, переключение нагрузки, бэкапы и т.п. — заскриптовано на API amazon.
В настоящее время несколько веб-кластеров готовятся к запуску у отечественного облачного провайдера Оверсан-Скалакси. Мы о них обязательно напишем и нарисуем.
Наши ближайшие технологические планы в области облаков и кластеризации
На прошедшей недавно партнерской конференции мы анонсировали, что сделаем в ближайшем релизе платформы 10.5, который выйдет осенью, поддержку облачных хранилищ: Amazon/S3, Google Storage, технологий хранения данных в Microsoft Azure.
Также, в версии 10.5, мы хотим предложить нашим клиентам решение, делающее их веб-кластер максимально надежным и… абстрагированным от облачного провайдера — чтобы в случае серьезных проблем в облаке/ДЦ, веб-кластер продолжил бесперебойно обслуживать клиентов в другом регионе облака/на другом континенте:
Cluster grid (это пока одно их рабочих названий технологии)
Мы с интересом смотрим на новейшие облачные технологии кластеризации и видим в них немалый потенциал для обеспечения надежности и производительности веб-проектов. Лучшие технологии мы будем продолжать реализовывать в платформе 1С-Битрикс — делая их полезными и доступными для наших многочисленных клиентов.
Желаю всем технологической удачи, оптимизма и до новых встреч в нашем корпоративном блоге!
Отказоустойчивый кластер для балансировки нагрузки
Поговорим о горизонтальном масштабировании. Допустим, ваш проект вырос до размеров, когда один сервер не справляется с нагрузкой, а возможностей для вертикального роста ресурсов уже нет.
В этом случае дальнейшее развитие инфраструктуры проекта обычно происходит за счет увеличения числа однотипных серверов с распределением нагрузки между ними. Такой подход не только позволяет решить проблему с ресурсами, но и добавляет надежности проекту — при выходе из строя одного или нескольких компонентов его работоспособность в целом не будет нарушена.
Большую роль в этой схеме играет балансировщик — система, которая занимается распределением запросов/трафика. На этапе ее проектирования важно предусмотреть следующие ключевые требования:
Фактически, это описание кластера, узлами которого являются серверы-балансеры.
В этой статье мы хотим поделиться рецептом подобного кластера, простого и неприхотливого к ресурсам, концепцию которого успешно применяем в собственной инфраструктуре для балансировки запросов к серверам нашей панели управления, внутреннему DNS серверу, кластеру Galera и разнообразными микросервисам.
Договоримся о терминах:
— Серверы, входящие в состав кластера, будем называть узлами или балансерами.
— Конечными серверами будем называть хосты, на которые проксируется трафик через кластер.
— Виртуальным IP будем называть адрес, “плавающий” между всеми узлами, и на который должны указывать имена сервисов в DNS.
Что потребуется:
— Для настройки кластера потребуется как минимум два сервера (или вирт.машины) с двумя сетевыми интерфейсами на каждом.
— Первый интерфейс будет использоваться для связи с внешним миром. Здесь будут настроены реальный и виртуальный IP адреса.
— Второй интерфейс будет использоваться под служебный трафик, для общения узлов друг с другом. Здесь будет настроен адрес из приватной (“серой”) сети 172.16.0.0/24.
Вторые интерфейсы каждого из узлов должны находиться в одном сегменте сети.
Используемые технологии:
VRRP, Virtual Router Redundancy Protocol — в контексте этой статьи, реализация «плавающего» между узлами кластера виртуального IP адреса. В один момент времени такой адрес может быть поднят на каком-то одном узле, именуемом MASTER. Второй узел называется BACKUP. Оба узла постоянно обмениваются специальными heartbeat сообщениями. Получение или неполучение таких сообщений в рамках заданных промежутков дает основания для переназначения виртуального IP на “живой” сервер. Более подробно о протоколе можно прочитать здесь.
LVS, Linux Virtual Server — механизм балансировки на транспортном/сеансовом уровне, встроенный в ядро Linux в виде модуля IPVS. Хорошее описание возможностей LVS можно найти здесь и здесь.
Суть работы сводится к указанию того, что есть определенная пара “IP + порт” и она является виртуальным сервером. Для этой пары назначаются адреса реальных серверов, ответственных за обработку запросов, задается алгоритм балансировки, а также режим перенаправления запросов.
В нашей системе мы будем использовать Nginx как промежуточное звено между LVS и конечными серверами, на которые нужно проксировать трафик. Nginx будет присутствовать на каждом узле.
Для настроек VRRP и взаимодействия с IPVS будем использовать демон Keepalived, написанный в рамках проекта Linux Virtual Server.
КОНЦЕПЦИЯ
Система будет представлять собой связку из двух независимых друг от друга равнозначных узлов-балансеров, объединенных в кластер средствами технологии LVS и протокола VRRP.
Точкой входа для трафика будет являться виртуальный IP адрес, поднятый либо на одном, либо на втором узле.
Поступающие запросы LVS перенаправляет к одному из запущенных экземпляров Nginx — локальному или на соседнем узле. Такой подход позволяет равномерно размазывать запросы между всеми узлами кластера, т.е. более оптимально использовать ресурсы каждого балансера.
Работа Nginx заключается в проксировании запросов на конечные сервера. Начиная с версии 1.9.13 доступны функции проксирования на уровне транспортных протоколов tcp и udp.
Каждый vhost/stream будет настроен принимать запросы как через служебный интерфейс с соседнего балансера так и поступающие на виртуальный IP. Причем даже в том случае, если виртуальный IP адрес физически не поднят на данном балансере (Keepalived назначил серверу роль BACKUP).
Таким образом, схема хождения трафика в зависимости от состояния балансера (MASTER или BACKUP) выглядит так:
РЕАЛИЗАЦИЯ:
В качестве операционной системы будем использовать Debian Jessie с подключенными backports репозиториями.
Установим на каждый узел-балансер пакеты с необходимым для работы кластера ПО и сделаем несколько общесистемных настроек:
На интерфейсе eth1 настроим адреса из серой сети 172.16.0.0/24 :
Виртуальный IP адрес прописывать на интерфейсе eth0 не нужно. Это сделает Keepalived.
В файл /etc/sysctl.d/local.conf добавим следующие директивы:
Первая включает возможность слушать IP, которые не подняты локально (это нужно для работы Nginx). Вторая включает автоматическую защиту от DDoS на уровне балансировщика IPVS (при нехватке памяти под таблицу сессий начнётся автоматическое вычищение некоторых записей). Третья увеличивает размер conntrack таблицы.
В /etc/modules включаем загрузку модуля IPVS при старте системы:
Параметр conn_tab_bits определяет размер таблицы с соединениями. Его значение является степенью двойки. Максимально допустимое значение — 20.
Кстати, если модуль не будет загружен до старта Keepalived, последний начинает сегфолтиться.
Теперь перезагрузим оба узла-балансера. Так мы убедимся, что при старте вся конфигурация корректно поднимется.
Общие настройки выполнены. Дальнейшие действия будем выполнять в контексте двух задач:
Вводные данные:
Начнем с конфигурации Nginx.
Добавим описание секции stream в /etc/nginx/nginx.conf :
И создадим соответствующий каталог:
Настройки для веб-серверов добавим в файл /etc/nginx/sites-enabled/web_servers.conf
Настройки для DNS-серверов добавим в файл /etc/nginx/stream-enabled/dns_servers.conf
Далее остается сконфигурировать Keepalived (VRRP + LVS). Это немного сложнее, поскольку нам потребуется написать специальный скрипт, который будет запускаться при переходе узла-балансера между состояниями MASTER/BACKUP.
При переходе в состояние MASTER, скрипт удаляет это правило.
Настройки LVS для группы веб-серверов:
Настройки LVS для группы DNS-серверов:
В завершении перезагрузим конфигурацию Nginx и Keepalived:
ТЕСТИРОВАНИЕ:
Посмотрим как балансировщик распределяет запросы к конечным серверам. Для этого на каждом из веб-серверов создадим index.php с каким-нибудь простым содержимым:
И сделаем несколько запросов по http к виртуальному IP 192.168.0.100 :
Если в процессе выполнения этого цикла посмотреть на статистику работы LVS (на MASTER узле), то мы можем увидеть следующую картину:
Здесь видно как происходит распределение запросов между узлами кластера: есть два активных соединения, которые обрабатываются в данный момент и 6 уже обработанных соединений.
Статистику по все соединениям, проходящим через LVS, можно посмотреть так:
Здесь, соответственно, видим то же самое: 2 активных и 6 неактивный соединений.
ПОСЛЕСЛОВИЕ:
Предложенная нами конфигурация может послужить отправным пунктом для проектирования частного решения под конкретный проект со своими требованиями и особенностями.
Если у вас возникли вопросы по статье или что-то показалось спорным — пожалуйста, оставляйте свои комментарии, будем рады обсудить.
Кластер серверов
Кластер серверов (Server Cluster) — это определенное количество серверов, объединенных в группу и образующих единый ресурс. Данное решение позволяет существенно увеличить надежность и производительность системы.
Сгруппированные в локальную сеть несколько компьютеров можно назвать аппаратным кластером, однако, суть данного объединения — повышение стабильности и работоспособности системы за счет единого программного обеспечения под управлением модуля (Cluster Manager).
Общая логика кластера серверов создается на уровне программных протоколов и дает возможность:
По сути, главной задачей кластера серверов, является исключение простоя системы. В идеале, любой инцидент, связанный с внешним вмешательством или внутренним сбоем в работе ресурса, должен оставаться незамеченным для пользователя.
При проектировании систем с участием серверного кластера необходимо учитывать возможности клиентского программного обеспечения по идентификации кластера и совместной работе с командным модулем (Cluster Manager). В противном случае вероятна ситуация, при которой попытка программы-клиента с помощью модуля получить доступ к данным ресурса через другие сервера может получить отказ (конкретные механизмы в данном случае зависят от возможностей и настроек кластера и клиентского оборудования).
Принято считать, что кластеры серверов делятся на две модели:
В обоих случаях, существуют определенные и вполне эффективные инструменты для решения проблем, поэтому выбор конкретной модели кластера неограничен ничем, кроме требований к архитектуре системы.
У вас похожая задача? Оставьте заявку, и наши специалисты свяжутся с вами в ближайшее время и подробно проконсультируют.