опубликовано:
Отказоустойчивость кластера: простыми словами для простых смертных ;)
Блондинка в ИТ – не парадокс, а всего лишь жизненная ситуация. ИТ-профиль деятельности компании, где я работаю, – это данность, цвет моих волос – тоже. Важна ведь не прическа, а то, что под ней ;) Простым и понятным языком я пытаюсь объяснить малообъяснимые вещи, которые воспринимаю отчасти интуитивно, отчасти в силу накопленного опыта и когда-то полученных в политехе знаний. Для чего? Очень просто: когда владелец бизнеса просит обеспечить ему оптимальное функционирование инфраструктуры или сайта, он рассчитывает на то, что ответственный за ИТ-отдел сотрудник выдаст ему решение с лучшим соотношением цена/качество. Однако, чтобы оценить аргументы айтишника, необходимо хотя бы на общем уровне понимать, о чем он говорит. Сегодня поговорим об отказоустойчивости.
Термин "отказоустойчивость" обычно используется в контексте оборудования. Если оно отказоустойчиво – значит, сбоев в работе не будет: не "упадет" сайт, или 1С, в которой вы работаете, не будет "виснуть" во время обработки массива данных по бухгалтерским проводкам, или скачок напряжения в банке не заблокирует вашу платежную карточку в тот момент, когда вы рассчитываетесь за покупку.
Отказоустойчивость кластера – это один из основных критериев качественной работы ЦОДа (центр обработки данных, aka дата-центр), которыми оперируют хостеры и которые очевидны для руководителя отдела ИТ в вашей компании, но не всегда очевидны для вас как владельца бизнеса. Между тем, понимать природу явления вам необходимо, принимая решение о размещении инфраструктуры вашего бизнеса на хостинге (например, у нас). Только так можно оценить предложения разных хостинг-провайдеров и выбрать оптимальный вариант для себя.
Итак, объясняю суть отказоустойчивости наглядно на бытовых и понятных всем примерах. У меня есть сын – вместе мы составляем семью, которую условно назовем кластером. По определению, кластер – группа одинаковых серверов (нод), выполняющих общие задачи и для клиентов представляемых в виде единой системы. Соответственно, я в этом кластере – нода 1, сын – нода 2. И есть наш кот, которого условно назовем клиентской рабочей станцией. С кластером клиент соединен аудиальным коммутационным каналом, по которому отправляет запросы на необходимые для него вещи («хочу есть» «хочу играть», «хочу, чтобы меня погладили», «хочу мяукать, чтобы меня выслушали» и т.д.) – аналогично тому, как интернет-соединение передает сигналы от клиента через терминал к удаленному серверу (с БД, инфраструктурой и т.д.).
Кот (клиент) отправляет запрос в виде голосового сообщения – и ему неважно, какая нода отреагирует. Если он приходит на кухню, где в это время нахожусь я (нода 1), и мяукает (коммутирует с сервером посредством канала), я насыплю ему корм (обработаю запрос). Если вместо меня на кухне сын (нода 2), корм (обработку запроса кластером) кот (клиент) получает от него. Таким образом, не важны средства, главное, что достигнута основная цель – удовлетворение запроса рабочей станции клиента. А какой из серверов был задействован, клиенту неважно. Вот это и есть отказоустойчивость кластера.
Смоделируем ситуацию, когда в ЦОДе (то бишь в нашей квартире) на кластере активна и доступна клиенту только нода 2 (сын). Скажем, я на работе и обработать запрос кота на получение еды (и/или сердечного общения) не могу. В этом случае инициативу обслуживания запроса клиента берет на себя нода 2 – сын насыпает корм, гладит кота, кот удовлетворенно мурлычет – клиент доволен, его запрос удовлетворен. Спустя некоторое время включается нода 1 (я возвращаюсь с работы), происходит копирование файлов в режиме реального времени с ноды 2 на ноду 1 (сын излагает героический эпос, посвященный спасению кота от голодной смерти и депрессии), нода 1 принимает информацию и старается жить с ней дальше, готовясь принимать дальнейшие запросы клиента.
Термин «время отклика» [системы] можно проиллюстрировать так: в кластере активны обе ноды (мы с сыном дома: сын играет в GTA, я сижу в блоге), клиент отправляет запрос (кот мяукает, требуя еды), но либо коммуникация нарушена, либо ноды перегружены (нам обоим не до кота сейчас!). Клиент ждет, отправляет запрос повторно – наконец, нода 2 берется за обработку запроса (сын идет кормить кота). Клиент сыт, но шибко недоволен, ибо время отклика системы оказалось большим, чем хотелось. Это фу и непростительно. Кот может обидеться и уйти спать в шкаф. Клиент, в общем-то, тоже – уйти. И для хостера эта проблема может оказаться гораздо ее, чем для котовладельцев.
Вариант исправления ситуации: когда клиент (проголодавшийся кот) отправляет запрос к кластеру (требовательно мяукает), перегруженная нода 2 переадресует этот запрос ноде 1 («Ма-а-ам, покорми кота, мне миссию прерывать нельзя!»), нода 1 подхватывает запрос и обрабатывает его (я откладываю блогопостинг и иду кормить кота). Это уже значительно улучшенный показатель отклика, клиенту он нравится гораздо больше! То есть чем меньше время отклика, тем выше отказоустойчивость.
Кроме того, в описании отказоустойчивости часто фигурирует так называемый балансировщик загрузки (aka HAProxy сервер). Именно он распределяет, какой ноде адресовать тот или иной запрос клиента, в зависимости от загруженности. После выполнения запроса информация от ноды-исполнителя копируется на ноду, не вовлеченную в выполнение, – для идентичности данных. В нашем кластере балансировщиком иногда выступает бабушка, которая получает запрос от кота и, видя, что я безнадежна погружена в блог, переадресовывает запрос клиента на менее занятую ноду 2 – ее внук послушно откладывает смартфон с FNaF’ом и идет кормить кота, затем отчитывается мне о свершенном подвиге. Таким образом, несмотря на свою занятость, я уже в курсе, что кот накормлен, и эти данные на ноде 1 и ноде 2 идентичны.
b_587e21f0ca85d.jpg
Все это верно для виртуальных машин. Коммутационный канал между кластерами обязательно должен быть налажен на «отлично». Для обеспечения отказоустойчивости этот канал должен работать без перебоев и обеспечивать обмен данными между кластерами в режиме реального времени. Чтобы клиент, удаленный от сервера, где располагается его база данных или инфраструктура (1С, CRM, система документооборота, сайт и т.д.) не испытывал неудобств, если на какое-то время вдруг один из кластеров откажет – дублирующий всегда подхватит запросы и обеспечит сервис.
И отдельным пунктом нашей сегодняшней повестки дня становится коммутация, обеспечиваемая интернет-провайдером. К сожалению, на нее влиять ЦОД не может. В нашем примере: если кот (клиент) открывает пасть, но не издаёт ни звука (отправляет запрос к кластеру, но ни одна нода его не получает), животное стоит показать ветеринару (повод поменять интернет-провайдера на более надёжного). Собственно, на этом всё.
Я спросила у знакомых специалистов, достаточно ли наглядны пояснения. Результаты соцопроса оказались положительными. Это хорошо мотивирует. В следующий раз я подберу другие жизненные примеры, чтобы приблизить ваше понимание загадочной терминологии ИТ и явлений, ею описываемых :)