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

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

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

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

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

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

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

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

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

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