А сейчас мы поиграем в ролевую игру. Но не бойтесь, не в ту, что с костюмом медсестры, горничной или чистильщика бассейна. Вы всего-навсего будете играть роль админа в… скажем так, непростой ситуации.
Игра начинается
Итак, представьте: вы рулите большим проектом с огромным парком серверов. Ваш проект — гигантский онлайн-магазин, продающий корм для хомяков с доставкой. А в хозяйстве у вас — 10.000 серверов. Менеджмент вашей компании готовится к взрывному росту бизнеса сразу после начала новой рекламной кампании в следующий понедельник. Поэтому стахановскими темпами менеджеры растят мощность инфраструктуры и в срочном порядке закупают еще 10.000 серваков.
Задача: в течение недели вписать все новые серверы в инфраструктуру, раскатать на них ваш магазин и все дополнительные сервисы. Что будете делать?
Для тех, кто любит побольнее: ручная настройка
Допустим, приложение, обеспечивающее работу вашего магазина, работает на кластере из тысячи серверов (остальные 9.000 рулят базами данных, бэкапами и кэшированием). Серверы спрятаны за двумя балансировщиками нагрузки (два балансера на одном доменном имени — тоже своего рода балансировка, ведь при обращении по доменному адресу юзер может попасть как на первый балансер, так и на второй).
Вы решаете нарастить мощность вашего магазина, добавив еще серверов с приложениями.
Вот так. А что осталось сделать? Осталось сообщить балансировщику нагрузки о том, что у него в кластере приложения в подчинении появилось еще, скажем, 1000 серверов. Для этого нужно пойти в настройки балансировщика и вписать там руками адреса новых машин.
И вот теперь все заработало, как надо.
Конечно, можно разок напрячься и руками вписать 1000 адресов в конфиги балансировщика. А что делать, если балансировщиков 500, а серверов приложений у них в подчинении 100 000? И они еще и меняют адреса, умирают, переезжают?
Для тех, кто любит контролировать: Service Discovery
Проблемы управления инфраструктурой в таких масштабах с успехом решает специальный журнал, в который серверы и компоненты инфраструктуры сообщают о своих адресах и состоянии, как только они появляются в кластере. Любые системы, которым нужно знать обо всех серверах, в курсе, что всё это можно узнать в этом журнале (если, конечно, у них есть на это права). Система, которая ведёт такой журнал, называется Service Discovery (SD). Посмотрим, как это работает.
Итак, вы засунули в ваш кластер приложения 1000 новых серверов приложений. Всем им админы задают адрес системы Service Discovery (например, с помощью системы автоматизации развертывания серверов), у которой надо прописаться, и немедленно шлют туда сообщение типа “Привет, я сервер приложения, я готов к работе, и вот мой адрес”.
Балансировщик нагрузки, вместо обращения к своим собственным файлам конфигов, раз в N секунд обращается в Service Discovery и запрашивает там список живых серверов приложений. После очередного цикла работы балансировщик получит обновленный список серверов приложений и начнет распределять нагрузку по всем новым машинам.
Поздравляю, мы только что перараспределили нагрузку в системе и включили новые серверы в кластер, не потратив на это ни секунды своего человеческого времени.
Стоп-слово и конец ролевой игры
Вот и закончилась наша ролевая игра в админа. Мы начали с болезненного опыта, в котором админ терпит унижения и боль, а закончили легким и приятным сценарием, в котором админ познает прелести Service Discovery и учиться доминировать над огромными парками серваков.
Начните внеднять Service Discovery в ваши проекты в тот момент, когда у вас в хозяйстве появляется 20-30 машин, и следуйте этой практике на каждом этапе роста вашей компании. Переезды, выход оборудования из строя и взрывной рост мощности всегда будут проходить гладко и быстро.
Оригинал статьи размещен здесь: https://mcs.mail.ru/blog/service-discovery/