Шаг 7. Обеспечение масштабируемости

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

Кейс: 100 тысяч администраторов постоянно что-то корректируют в обе руки. И все корректно и целостно на любом этапе.

Начинаем с самого простого, один сайт – один сервер:

overload_srv1

Нагружаем систему. Раскаляется WS, пыхтит SDC. В тот момент, когда выясняется, что load average (совокупная загрузка процессора, памяти и диска) на сервере подходит к половине предела, стоит добавить в инфраструктуру и конфигурацию еще один сервер. Что это значит при наличии на сайте одного сервера? Например, разнести функциональные роли WS и DC по разным серверам в конфигурации. Нагрузка на IC в рассматриваемом кейсе небольшая, поэтому в предположении что нагрузка на SDC меньше, оставим его на сервере с функциональной ролью SDC:

overload_2srv

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

overload_ws

Нагружаем еще. Становится "трудно дышать" серверу с SDC. И что же с ним делать? Ведь его можно только зарезервировать в режиме Active-Passive, а значит в пределах сайта он не размножается аналогично WS. Перевод нагрузки на другой сайт не будет решением – на мастер-сайте работает такой же MDC с таким же резервированием Active-Passive, и нагрузка сосредоточится на нем и застопорит общее масштабирование. Тут приходит на помощь многодоменная структура. Формируем доменное дерево, ограничиваем количество сущностей в каждом домене, в том числе и трудящихся в них администраторов. Добавляем в инфраструктуру сервер и создаем в конфигурации для сайта несколько групп функциональных ролей SDC. Они привязываются к доменным зонам и на этом основании их может быть несколько активных одновременно. Они не резервируют друг друга, а дополняют в части объединения в полное доменное дерево. И у каждого может быть резервный экземпляр. Признак резервности – тот же индекс группы и как следствие тот же набор параметров, в том числе связь с доменными зонами. Наши 100 тысяч администраторов распределились по некоторому количеству доменов, нагрузка на серверы распределилась, потенциал для дальнейшего повышения нагрузки обретен.

overload_dc

В этой схеме есть два сервера, не имеющие активных сервисов (Server2 и Server4), и можно было бы переместить две функциональных роли WS на них, сэкономив пару серверов (удалить из конфигурации Server6 и Server7). Целесообразность подобного уплотнения функциональных ролей на сервере зависит от дополнительных внешних требований и условий. В качестве аргументов против уплотнения можно привести следующие:

  • ObjectDB на Server2 и Server4 в рассматриваемом кейсе занимается плотной работой по синхронизации транзакций.

  • В реальном примере серверы Server2 и Server4 будут нагружены другими полезными функциональными ролями и видимая пустота будет отсутствовать.

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

Дальше можно наращивать серверы, добавлять функциональные роли WS, добавлять домены, добавлять функциональные роли SDC на рабочем сайте и аналогично MDC на мастер-сайте. Мы упремся только в пропускную способность сети – между серверами одного сайта, а также между рабочим сайтом и мастер-сайтом. Вполне можно приблизительно рассчитать предел этой нагрузки для каждого значения пропускной способности сети внутри сайта и между сайтами.

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

Кстати, валидатор конфигурации на MIC не позволит провести неверную настройку групп функциональных ролей. То есть не разрешит:

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

  • задать разные настройки экземплярам одной группы.

Table 1. Используемые термины
Термин Определение

Масштабирование

!

Хэшринг

!

Группа функциональных ролей

!

Индекс группы

!