42
Рисунок 2.16: Передача данных по HTTPS
После установления TCP соединения между клиентом и сервером,
которые заинтересованы в безопасной передаче данных, участники SSL
соединения производят обмен ключами и согласовывают подходящий
алгоритм шифрования. После того, как SSL соединение установлено,
протоколы верхних уровней могут обмениваться информацией. Самый
используемый протокол поверх SSL – это HTTP (HTTPS – это обычный HTTP,
зашифрованный с помощью SSL).
Рисунок 2.16 иллюстрирует передачу данных с помощью HTTPS, вместе
с TCP и SSL рукопожатиями.
Балансировщик, предоставляющий функцию SSL offload может
представляться клиенту как SSL сервер, SSL клиентом реальному серверу, или
представляться обоим SSL клиентом или сервером.
43
На рисунке 2.17 показана функция SSL терминации, на рисунке 2.18
функция SSL инициации, а на рисунке 2.19 функция сквозного SSL.
Рисунок 2.17: SSL offload
Рисунок 2.18: SSL Инициация
Рисунок 2.19: Сквозной SSL
SSL терминация может окончательно освободить сервера от выполнения
функции шифрования. Это самый распространённый способ внедрения SSL
offload, и он даёт следующие преимущества:
Полное освобождение серверов от функции шифрования
Позволяет балансировщику использовать механизмы балансировки
верхних уровней (5-7), такие как URL балансировка.
Требуется меньше сертификатов, т.к. в данной схеме, только
балансировщику требуется сертификат.
При использовании SSL инициации, балансировщик может производить
SSL рукопожатие вместо клиента. К примеру, этим клиентом может быть
сервер в дата-центре “А”, передающий информацию по незащищённому
каналу в дата-центр “Б”. Такой дизайн полезен в том случае, если SSL сервер
доступен только через интернет, и администраторы дата-центра хотят снять с
серверов нагрузку шифрования. Также, в данном случае, можно сохранить
44
финансы на сертификатах, т.к. в данном случае, только балансировщику
необходим сертификат. [1]
В некоторых компаниях, политиками безопасности запрещена передача
данных по любым незащищенным каналам (Например, если эта компания -
банк). В этом случае, метод сквозного SSL подойдет, т.к. он даёт следующие
преимущества:
Позволяет использовать балансировку на 7-м уровне, не теряя при этом
в безопасности.
Может использовать менее ресурсно-затратное шифрование на
серверах.
Только балансировщику необходим публичный сертификат, сервера
могут использовать приватные сертификаты.
2.10 TCP offload
Когда сервер использует TCP для общения с клиентами, ему необходимо
выполнять следующие действия:
Устанавливать соединение (тройное рукопожатие)
Подтверждать получение сегментов
Выполнять проверку контрольной суммы
Выполнять проверку Sequence number
Управлять механизмом скользящего окна
Управлять механизмом контроля перегрузки
Завершать соединение
В зависимости от характеристик соединения, сервер может тратить на
эти операции большое количество оперативной памяти и процессорного
времени. Балансировщик нагрузки может использовать свои ресурсы, чтобы
разгрузить сервера от выполнения большей части функций TCP. Рисунок 2.20
показывает каким образом балансировщик уменьшает количество соединений
на сервер.
45
Рисунок 2.20: TCP Offload
Вместо того, чтобы сервер обслуживал соединения от всех
пользователей, балансировщик может передавать все данные передаваемые в
этих сессиях через одну TCP сессию для каждого сервера.
2.11 Сжатие HTTP
Большинство веб-серверов и браузеров имеет функцию сжатия
передаваемых данных для:
Уменьшения объёма передаваемых данных.
Ускорения времени ответа веб-страниц.
Самые распространённые алгоритмы сжатия в данный момент – это
GZIP и deflate. Процесс сжатия, обычно, потребляет значительное количество
ресурсов, таких как оперативная память и процессорное время. В зависимости
от количества одновременных запросов и размера HTTP объектов, включение
сжатия может серьёзно ухудшить время ответа веб-сервера.
Т.к. большая часть трафика, обычно, передаётся от сервера к клиенту,
для сжатия можно использовать балансировщик нагрузки. В данном случае,
балансировщик может узнать какой тип сжатия использует клиент, и от лица
веб-сервера сжимать данные. Таким образом, балансировщик экономит
вычислительные ресурсы серверов.
46
2.12 GeoDNS и Anycast маршрутизация
Domain Name System (DNS) – это очень важная часть современных
информационных систем. С его помощью, пользователи производят
трансляцию доменных имён в ip-адреса и обратно. Для балансировки, как
правило, используется ряд А-записей для одного и того же домена.
Как описано на рисунке 2.21, для домена www.company.com
сконфигурировано 2 A-записи. DNS сервер может отвечать на клиентские
запросы разными A-записями, балансировка производится по методу round-
robin. В качестве адресов в A-записях может фигурировать любой ip-адрес, в
том числе ip-адрес балансировщика. [32]
Рисунок 2.21: Балансировка посредством A-записей в DNS
Хотя DNS балансировка нагрузки очень проста в настройке, она имеет
ряд недостатков:
DNS сервер не берёт в расчёт состояние серверов между которыми он
балансирует нагрузку. Возможна ситуация, в которой клиенту будет
передан адрес нерабочего сервера.
DNS сервер не берёт в расчёт нагрузку на каждый отдельный сервер.
Возможна ситуация, в которой сервер приложения будет перегружен
запросами, что серьёзно повлияет на качество предоставления сервиса
клиенту.
47
DNS балансировка не описывает тип трафика, который использует
клиент, а также, не описывает тип устройства (телефон, компьютер,
планшет), которое использует клиент. В результате, балансировка не
может основываться на этих параметрах.
Представим, что веб-сервер www.company.com находится в 2-х разных
дата-центрах. Что будет, если один из дата-центров по каким-либо причинам
будет выведен из строя? В описанной выше схеме, веб-сервер
www.company.com просто перестанет работать для пользователей, которым
DNS-сервер отдал ip-адрес неработающего дата-центра. Есть и другая
проблема в данном подходе. Представьте, что эти дата-центры расположены
на разных континентах. Сервер 172.31.20.1 находится в Лос-Анджелесе, а
172.31.20.2 в Москве. Если мы будем использовать простую DNS
балансировку, то часть пользователей из Лос-Анджелеса будут вынуждены
обращаться к серверу в Москве, и наоборот, пользователи из Москвы в Лос-
Анджелес, тем самым обрекая себя на высокое время отклика интересующего
их ресурса. [31]
Для таких случаев существует сервис GeoDNS. GeoDNS определяет
какой пользователь запрашивает DNS-запись, и может отвечать записью
ближайшего к инициатору сервера. Параметры, по которым определяется
местонахождение инициатора могут быть следующими:
Базы данных GeoIP. Например, maxmind.com.
Автономная система пользователя.
Заданные административно фильтры.
Пример работы GeoDNS сервиса показан на рисунке 2.22.
Рисунок 2.22: Пример работы GeoDNS сервиса
48
Качественная настройка GeoDNS очень непростая задача. Тем не менее,
данная задача находится за пределами обсуждаемых в данной работе тем, и
детально рассмотрена не будет.
Тем не менее, при выходе из строя одного из дата-центров, DNS-сервер
продолжит отвечать пользователям адресом неработающего сервера. Более
того, даже если сервер узнает о том, что дата-центр выведен из эксплуатации,
существует проблема с кэшированием DNS-записи на стороне клиента. Здесь
в игру вступает техника динамической маршрутизации, называемая Anycast.
Anycast – это такой тип маршрутизации, где несколько маршрутизаторов
анонсируют один и тот же префикс, и кратчайший путь к анонсируемой
подсети выбирается на основе тех или иных метрик внутри протокола
динамической маршрутизации. Пример anycast маршрутизации с
применением протокола BGP показан на рисунке 2.23. В данном случае,
подсеть 172.31.20.0/24 анонсируется из одной автономной системы, но с
разных точек присутствия. Согласно механизму выбора кратчайшего пути, в
BGP кратчайшим путём будет выбран путь с AS_PATH с одной автономной
системой в нём. В случае, если лучший путь пропадёт из BGP таблицы роутера
R1, будет установлен маршрут через R3, и пользователи будут попадать на
вторую точку присутствия. Данный метод примечателен тем, что пользователь
может продолжать использовать тот адрес, который получил от DNS-сервера.
Сервис для него продолжит работать, но время ответа сервиса для
пользователя может увеличиться.
Таким образом, мы можем анонсировать одну и ту же подсеть из разных
точек земного шара, и трафик до этой подсети автоматически будет попадать
на ближайшую (по мнению BGP) точку присутствия. Тем не менее,
информация из AS_PATH далеко не всегда отражает информацию о
кратчайших путях с точки зрения времени ответа. Только сочетание GeoDNS,
Anycast и других техник позволяет добиться кратчайшего времени ответа от
сервиса из любой точки мира. Данные методы балансировки нагрузки широко
применяются в современных информационных системах, в том числе для
организации CDN (Content delivery network). CDN, сам по себе, является очень
большой темой, поэтому находится за пределами данной дипломной работы и
конфигурации с применением CDN здесь рассмотрены не будут. [33]
49
Рисунок 2.23: Anycast маршрутизация
50
Практическая реализация балансировки трафика
территориально распределенных ЦОД на тестовой среде
3.2 Выбор решения по балансировке нагрузки и его внедрение
Выбор решения по балансировке нагрузки напрямую зависит от
следующих параметров:
Объём пользовательского трафика
Количество одновременных пользовательских соединений
Тип используемого серверного приложения
Соглашение об уровне сервиса (SLA) который необходим пользователю
Тип устройств, на которые будет происходить балансировка
Существует большое количество устройств для балансировки. Самые
популярные компании-производители такого типа устройств – это компании
F5 и Citrix. Данные продукты, обычно, выпускаются как в качестве
самостоятельного устройства, так и в качестве программного решения,
разворачиваемого на платформе виртуализации, такой, например, как
VMware. Продукты данного типа позволяют производить балансировку на
уровнях 4-7 модели OSI. Они также, зачастую, включают в себя
дополнительный функционал, такой, например, как WAF (Web application
firewall), SSL offload и т.д. Данные решения являются дорогостоящими и их
стоит выбирать только в том случае, если вам необходим дополнительный
функционал, поддержка, или бесплатные решения не удовлетворяют объём
пользовательского трафика.
Существуют и бесплатные решения, но они, как правило, лишены части
функционала и, зачастую, не имеют поддержки. Тем не менее, данные
продукты имеют свою сферу применения, а также, не требуют значительных
финансовых вложений, что часто является ключевым в выборе такого типа
решений. Одно из таких решений – это Keepalived. Он представляет из себя
ряд сервисов, образующих вместе комплекс для балансировки и обеспечения
высокой доступности балансировщиков. Данный комплекс поставляется как
дистрибутив для Linux систем, и включает в себя несколько компонентов.
Основными компонентами Keepalived являются:
IPVS (модуль ядра, который управляет балансировкой на 4-м уровне
модели OSI)
VRRP (Virtual Redundancy Routing Protocol) модуль
51
3.2 Описание технологий, используемых в практической части
Ввиду высокой популярности и простоты настройки Keepalived, как
средства балансировки, для практической части данной работы будет
использован именно он. Как операционную систему для приложений и как
платформу для балансировщика, мной будет использован дистрибутив Ubuntu
16.04. Для динамической маршрутизации внутри дата-центров будет
использован протокол OSPF. На балансировщиках будет использован демон
маршрутизации Quagga. Роль роутеров будут выполнять устройства Cisco
ASR 1001x. Я также буду использовать ASN5 как номер автономной системы
в которой будут находиться наши дата-центры. Как адреса для балансировки
будут использованы сети 5.0.0.0/24 и 5.0.1.0/24. Как предоставляемый
клиентам сервис, я буду использовать дистрибутив apache2, а как доменное
имя для данного сервиса я буду использовать домен “example.com”. На
рисунке 3.1 показана используемая для практической части топология.
На рисунке 3.1 изображена логическая топология сети тестового стенда.
На рисунке 3.2 изображена Физическая топология каждого из дата-центров.
Все устройства подключены к паре коммутаторов Nexus 5548. Сами
коммутаторы Nexus 5548 находятся в VPC кластере.
Рисунок 3.1: Логическая топология