Клиент-серверная архитектура в HighLoad-системах | OTUS
⚡ Подписка на курсы OTUS!
Интенсивная прокачка навыков для IT-специалистов!
Подробнее

Курсы

Программирование
Backend-разработчик на PHP Алгоритмы и структуры данных Team Lead Архитектура и шаблоны проектирования Разработчик IoT C# Developer. Professional HTML/CSS
-11%
C# ASP.NET Core разработчик
-5%
Kotlin Backend Developer
-8%
iOS Developer. Professional
-8%
Symfony Framework Unity Game Developer. Basic JavaScript Developer. Professional Android Developer. Basic JavaScript Developer. Basic Java Developer. Professional Highload Architect Reverse-Engineering. Professional Java Developer. Basic Web-разработчик на Python Framework Laravel Cloud Solution Architecture Vue.js разработчик Интенсив «Оптимизация в Java» Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes Супер-интенсив "Tarantool" PHP Developer. Basic
Инфраструктура
Мониторинг и логирование: Zabbix, Prometheus, ELK Administrator Linux. Professional Дизайн сетей ЦОД Разработчик IoT PostgreSQL Экспресс-курс "Версионирование и командная работа с помощью Git"
-30%
Microservice Architecture Highload Architect MS SQL Server Developer Разработчик программных роботов (RPA) на базе UiPath и PIX Разработчик голосовых ассистентов и чат-ботов Administrator Linux. Advanced Infrastructure as a code Супер-практикум по использованию и настройке GIT Administrator Linux.Basic Экспресс-курс «IaC Ansible» Экспресс-курс «CI/CD или Непрерывная поставка с Docker и Kubernetes» Основы Windows Server
Корпоративные курсы
Безопасность веб-приложений IT-Recruiter Дизайн сетей ЦОД Компьютерное зрение Разработчик IoT Вебинар CERTIPORT Machine Learning. Professional
-6%
NoSQL Пентест. Практика тестирования на проникновение Java QA Engineer. Базовый курс Руководитель поддержки пользователей в IT
-8%
SRE практики и инструменты Cloud Solution Architecture Внедрение и работа в DevSecOps Супер-практикум по работе с протоколом BGP Infrastructure as a code Супер-практикум по использованию и настройке GIT Промышленный ML на больших данных Экспресс-курс «CI/CD или Непрерывная поставка с Docker и Kubernetes» BPMN: Моделирование бизнес-процессов Основы Windows Server
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

Клиент-серверная архитектура в HighLoad-системах

Если сервис недоступен пользователям определённое время, это плохо, но не смертельно. Зато потерять данные клиента — попросту недопустимо. Именно поэтому важно скрупулёзно оценивать применяемые технологии хранения данных. Кроме того, важно обеспечить избыточность при построении клиент-серверной архитектуры. Об этом и поговорим.

Наиболее простым примером распределённой системы является классическая клиент-серверная модель. В нашем случае сервер является точкой синхронизации, которая даёт возможность осуществлять совместные и скоординированные действия сразу нескольким клиентам.

Рассмотрим упрощённую схему клиент-серверного взаимодействия: jqhyeeqxfebgrvhzvkwsrz58jhy_2-20219-5e38a7.png

Что тут ненадёжного? Все мы знаем, что сервер может упасть. А когда это произойдёт, все клиенты работать не смогут. Дабы избежать этой ситуации, было придумано подключение master-slave (теперь его называют leader-follower). Суть проста: существуют 2 сервера, клиенты взаимодействуют с главным сервером, а на второй сервер осуществляется репликация данных.

Схема клиент-серверной архитектуры с репликацией данных на фолловера: tkbovuwxni03qjfpkx7m5iwmfie_2-20219-175daa.png

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

Тут имеет значение и то, каким образом устроена репликация. Если репликация синхронная, транзакцию надо сохранять одновременно как на лидере, так и на фолловере, что бывает медленно. Если же репликация асинхронная, после аварийного переключения мы можем потерять часть данных.

Но давайте представим, что лидер упадет ночью во время спокойного и крепкого сна. Да, данные на фолловере есть, однако никто ведь фолловеру не сказал, что теперь он лидер, следовательно, клиенты к нему подключиться не смогут. Но мы можем наделить фолловер логикой, в результате чего он начнёт считать себя главным, когда будет потеряна связь с лидером. Но и здесь есть подводные камни: split brain — конфликт, при котором связь между лидером и фолловером нарушается, и оба начинают думать, что они являются главными.

Для решения вышеописанных проблем организуют auto failover — в этом случае добавляется третий, «свидетельский» сервер (witness). Такой сервер гарантирует наличие лишь одного лидера. Если же лидер отваливается, фолловер включится автоматически в кратчайшие сроки. Разумеется, в такой схеме клиенты должны знать адреса лидера и фолловера заранее. Также должна быть реализована логика автопереподключения между ними.

На схеме ниже видно, что witness гарантирует наличие одного лидера. И если лидер отваливается, включение фолловера происходит автоматически: n1veaqz67xiw_ozn0cnsudwx7cw_2-20219-8ccfd2.png

Но есть минусы и у этой схемы. Допустим, вы обновляете на лидер-сервере операционную систему. А до этого вручную переключили на фолловера нагрузку — вдруг он падает, и сервис становится недоступен. Это катастрофа… Чтобы от неё застраховаться, надо добавить 3-й резервный сервер — то есть мы говорим об ещё одном фолловере. Вуаля — надёжность увеличивается, то есть 2 сервера — это мало, лучше три: один на обслуживании, второй упал, но есть третий и катастрофы не происходит.

Вот, как это может выглядеть: 57etao8c03_skbgh4_evsna3vwu_2-20219-0dce37.png

Делаем вывод

Итак, избыточность должна быть. Мало того, она должна быть равной двум, так как избыточности, которая равняется единице, явно недостаточно для достижения требуемого уровня надёжности. Кстати, именно поэтому в дисковых массивах стали вместо RAID5 использовать схему RAID6, которая переживает падение сразу 2-х дисков.

Статья подготовлена по материалам блога компании Pyrus.

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться