А сейчас мы поиграем в ролевую игру. Но не бойтесь, не в ту, что с костюмом медсестры, горничной или чистильщика бассейна. Вы всего-навсего будете играть роль админа в… скажем так, непростой ситуации.

Игра начинается

Итак, представьте: вы рулите большим проектом с огромным парком серверов. Ваш проект — гигантский онлайн-магазин, продающий корм для хомяков с доставкой. А в хозяйстве у вас — 10.000 серверов. Менеджмент вашей компании готовится к взрывному росту бизнеса сразу после начала новой рекламной кампании в следующий понедельник. Поэтому стахановскими темпами менеджеры растят мощность инфраструктуры и в срочном порядке закупают еще 10.000 серваков.

Задача: в течение недели вписать все новые серверы в инфраструктуру, раскатать на них ваш магазин и все дополнительные сервисы. Что будете делать?

Для тех, кто любит побольнее: ручная настройка

Допустим, приложение, обеспечивающее работу вашего магазина, работает на кластере из тысячи серверов (остальные 9.000 рулят базами данных, бэкапами и кэшированием). Серверы спрятаны за двумя балансировщиками нагрузки (два балансера на одном доменном имени — тоже своего рода балансировка, ведь при обращении по доменному адресу юзер может попасть как на первый балансер, так и на второй).

 

 

Вы решаете нарастить мощность вашего магазина, добавив еще серверов с приложениями.

 

 

Вот так. А что осталось сделать? Осталось сообщить балансировщику нагрузки о том, что у него в кластере приложения в подчинении появилось еще, скажем, 1000 серверов. Для этого нужно пойти в настройки балансировщика и вписать там руками адреса новых машин.

 

 

И вот теперь все заработало, как надо.

Конечно, можно разок напрячься и руками вписать 1000 адресов в конфиги балансировщика. А что делать, если балансировщиков 500, а серверов приложений у них в подчинении 100 000? И они еще и меняют адреса, умирают, переезжают?

Для тех, кто любит контролировать: Service Discovery

Проблемы управления инфраструктурой в таких масштабах с успехом решает специальный журнал, в который серверы и компоненты инфраструктуры сообщают о своих адресах и состоянии, как только они появляются в кластере. Любые системы, которым нужно знать обо всех серверах, в курсе, что всё это можно узнать в этом журнале (если, конечно, у них есть на это права). Система, которая ведёт такой журнал, называется Service Discovery (SD). Посмотрим, как это работает.

Итак, вы засунули в ваш кластер приложения 1000 новых серверов приложений. Всем им админы задают адрес системы Service Discovery (например, с помощью системы автоматизации развертывания серверов), у которой надо прописаться, и немедленно шлют туда сообщение типа “Привет, я сервер приложения, я готов к работе, и вот мой адрес”. Service Discovery принимает подобные запросы не только от серверов приложений, но и от любых инфраструктурных компонентов в сети. В итоге получается, что этот сервис-всезнайка может в любой момент точно сказать, какие серваки есть в сети, что они делают и где живут.

Балансировщик нагрузки, вместо обращения к своим собственным файлам конфигов, раз в N секунд обращается в Service Discovery и запрашивает там список живых серверов приложений. После очередного цикла работы балансировщик получит обновленный список серверов приложений и начнет распределять нагрузку по всем новым машинам.

Поздравляю, мы только что перараспределили нагрузку в системе и включили новые серверы в кластер, не потратив на это ни секунды своего человеческого времени.

 

В Service Discovery можно запихивать любые компоненты инфраструктуры — базы данных, серверы кэширования, микросервисы, резервные машины.

При любых изменениях в системе все заинтересованные части получат обновленные состояния инфраструктуры и изменят свою работу под новые условия. А заинтересованных агентов обычно много — балансировщики желают знать свои кластеры приложений, приложения хотят знать свои СУБД и системы кеширования, системы мониторинга хотят знать сервисы, подлежащие наблюдению… Короче, желающих быть в курсе дел вашей инфраструктуры набирается много. А изменения состояний — это не только появление новых серверов, но и их выход из строя, переезд, перенос между подсетями. Как хорошо, что всё это решает Service Discovery!

Какие бывают Service Discovery?

ZooKeeper

Проект от Apache Foundation, пионер концепции Service Discovery. Написан на Java, крепок и стабилен, но тяжеловат в настройке и уступает по многим параметрам его более современным потомкам. Сегодня хорош, скорее, в качестве музейного экспоната и экскурса в историю динозавров. При разработке новых приложений его лучше не использовать.

Etcd

Простой, как топор, быстрый и очень гибкий продукт. В нем можно регистрировать серверы, хранить конфиги и держать состояния всех компонентов вашей инфраструктуры.

Крайне прост и надежен, но лишён многих полезных фич. Прекрасный выбор для тех, кому важна скорость и гибкость.

Consul

Пожалуй, лидер современного топа Service Discovery. Чуть более тяжелый и медленный, чем Etcd, но взамен предлагающий кучи крутых плюшек. Например, веб-интерфейс для работы со списками сервисов.

Kubernetes

Kubernetes умеет дофига всего, в том числе и Service Discovery. Это не его основное предназначение, он создавался совсем для других целей. Но для ряда проектов (особенно для тех, кто всё упаковывает в контейнеры и строит из них крупные кластеры) средства Service Discovery, предлагаемые Kubernetes по умолчанию, вполне сойдут.

Стоп-слово и конец ролевой игры

Вот и закончилась наша ролевая игра в админа. Мы начали с болезненного опыта, в котором админ терпит унижения и боль, а закончили легким и приятным сценарием, в котором админ познает прелести Service Discovery и учиться доминировать над огромными парками серваков.

Начните внеднять Service Discovery в ваши проекты в тот момент, когда у вас в хозяйстве появляется 20-30 машин, и следуйте этой практике на каждом этапе роста вашей компании. Переезды, выход оборудования из строя и взрывной рост мощности всегда будут проходить гладко и быстро.

Источник иллюстрации в шапке — wallscloud.net