Аппаратная архитектура высоконагруженных систем

Привет!

У Сатаны много имён, но у высоконагруженных систем (ВНС) их, возможно, даже больше. И хотя не все точно отражают суть (вернее — отражают частные случаи), сисадмины, ИТ-архитекторы и прочие инженеры активно используют их в своей речи:

• Highload-системы (хайлоад) — английская версия, наиболее частый в употреблении и точный синоним, главное — в меру;

• HPC-системы или HPC-кластеры (High Performance Computing / высокопроизводительные вычисления) — примерно то же самое, но с акцентом на высокую производительность вычислений;

• Суперкомпьютеры — акцент на максимальную производительность.

• Системы обработки больших данных (Big Data) — фокус на работе с огромными объёмами данных;

• Облачные платформы высокой доступности —  облачные сервисы от провайдеров с высокими показателями отказоустойчивости;

• Системы массового обслуживания (СМО) — для обслуживания большого количества пользователей;

• Масштабируемые системы — системы, которые при увеличении нагрузки могут поддерживать работу на таком же уровне производительности и надёжности (или даже улучшать показатели).

• Децентрализованные или геораспределённые системы (вычисления) — если архитектура предполагает распределение нагрузки между узлами, которые физически находятся в разных местах.

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

И ещё много перечислить можно. Но в этой статье я буду говорить о высоконагруженных системах и их архитектуре в целом, а не о частностях (хотя в примерах мы к ним вернёмся). При этом затрагивать будем только аппаратную часть, а программную обсудим в следующей статье про архитектуру ВНС.

Информации будет много, так что можете смело заваривать термос чего-нибудь горячего.

Что такое высоконагруженная система: программно-аппаратный комплекс и кластеры

“Всё айти — это система высоконагруженных костылей”, — неизвестный автор.

Высоконагруженная система (ВНС, она же хайлоад-система) — это не просто компьютер или сервер, а сложная связка программного обеспечения и оборудования: ВНС не получится создать только лишь программно или развернуть на очень надёжных серверах без специального ПО. Нужна тесная интеграция железа и софта — этакий программно-аппаратный комплекс (ПАК).

Цель у хайлоад-систем “простая” — эффективная обработка огромного объёма запросов и данных в сложных условиях, когда десятки/сотни/тысячи/миллионы пользователей интенсивно используют систему по назначению. Она должна работать стабильно: без просадок в производительности, без отказов, без ошибок. Это также значит, что ни один из компонентов системы не должен стать бутылочным горлышком (например, процессор не должен простаивать из-за медленной памяти).

Типичные примеры, где высоконагруженная система нужна:

• Крупный интернет-магазин или маркетплейс (e-commerce), у которого идёт распродажа перед рождеством или в чёрную пятницу;

• Крупный релиз (сериал или фильм) на стриминговой платформе вечером в выходной, когда нагрузка на серверы и без того большая;

• Популярные социальные сети, там всегда высокие нагрузки, и бывают дополнительные всплески активности пользователей;

• Крупные банки, обрабатывающие миллионы транзакций;

• Гиперскейлы — поставщики облачных услуг, которые продают мощности своих дата-центров в аренду. Их инфраструктура должна быть построена на принципах высоконагруженных систем.

И в любых других областях, где производительность и высокая доступность серверов и приложений критически важны. По сути, если что что-то работает в режиме 24/7 с большим количеством запросов, то это про высокие нагрузки (с исключениями, разумеется).

Архитектура высоконагруженных систем: песнь софта и железа

Подчеркну, что highload-системы — это не универсальный инструмент для всего и вся, а решение для конкретных задач. Нужно это решение или нет (а также его сложность), зависит от бизнес-целей, бюджета и прогнозируемой нагрузки.

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

Поскольку ВНС — это комплекс из софта и железа, то и архитектурно здесь две части: аппаратное обеспечение (АО) и программное обеспечение (ПО). Напомню, что в этой статье будет только об АО, но следом в блоге выйдет статья про программную архитектуру высоконагруженных систем.

Серверы всему голова: коммутаторы, системы хранения данных, сетевое оборудование

Серверы — это фундамент высоконагруженной системы. Серверы, а не сервер. Ни одно отдельное устройство нельзя считать высоконагруженной системой (высоконагруженным сервером — пожалуйста), так как система подразумевает наличие нескольких узлов (нод). Суперкомпьютер, например, это не один сверхмощный компьютер, а кластер из сотен и тысяч вычислительных серверов, соединённых скоростными шинами и коммутаторами, вроде HPE Cray XD2000. А суперкомпьютер — как мы помним из введения — это частный случай ВНС.

Дата-центр мирового лидера высокопроизводительных вычислений — Frontier

В теории ВНС можно построить почти на любом оборудовании (хоть на смартфонах или ноутбуках в кластере), можно даже какого-то уровня надёжности добиться. Но так как серверы изначально проектируются для круглосуточной работы в условиях повышенных нагрузок, то это идеальный кандидат. Любые коммерческие хайлоад-системы основаны именно на серверах, системах хранения данных (СХД — те же серверы, но в роли хранилища), коммутаторах и другом профессиональном оборудовании. И всё это добро объединено в сеть, а нагрузка распределяется между узлами.

Почему именно сервер?

Во-первых, есть аппаратная отказоустойчивость: резервирование компонентов (блоки питания, вентиляторы, сетевые платы, накопители) и некоторые из них можно обслуживать прямо по ходу работы (hot-swap). А в составе ВНС можно обслуживать целый сервер (и не один) без остановки процессов.

Во-вторых, в серверах есть полезные технологии, вроде памяти с коррекцией ошибок (ECC), которая автоматически распознаёт и исправляет спонтанно возникшие изменения битов памяти — архиважная штука при работе с большим объёмом данных. Или же количество компонентов в одном устройстве: 2 или 4 процессора, слоты расширения, десятки терабайт памяти, сотни терабайт хранилища быстрого хранилища и т.д.

Сколько бы адепты развёртывания бизнес-задач на ПК не били себя в грудь — серверные компоненты надёжнее консьюмерских: процессоры, накопители, блоки питания уровня Platinum и Titanium и т.д. Наработка на отказ (Mean time between failures, MTBF) исчисляется по 10-15+ лет, а на некоторые компоненты и по 100+ лет. Но да, и обычный процессор в вашем ноутбуке может проработать лет 20 без проблем, тут как повезёт.

Когда собрал отказоустойчивый кластер для ВНС на старом железе с алиэкспресс и учишь этому админа-новчика.

Ещё одно важное отличие серверов — эффективная и при этом надёжная система охлаждения, которая позволяет отводить огромные объёмы тепла из очень плотной компоновки комплектующих. Из-за этого серверы шумят, как самолёты на взлёте, но это не проблема, так как работают они в отдельных помещениях (желательно под замком).

В итоге серверы дают максимум надёжности и вычислительной мощности (те же процессоры могут работать при огромных TDP со штатными системами охлаждения) в пересчёте на занимаемое пространство. Так что высоконагруженная система для бизнеса должна строиться на серверном оборудовании, а не на самосборе из железа с алиэкспресс. Хотя для домашних систем или простых инсталляций можно и франкенштейна собрать без претензий на успешный успех. 

Как и всегда с серверами — есть вариативность. Обычно используют один из подходов: сделать дорого и богато или взять количеством. Можно собрать всё из небольшого количества сверхнадёжных и производительных серверов — с резервированием компонентов; а можно сделать ВНС из десятков/сотен/тысяч (нужное подчеркнуть) недорогих серверов. И оба подхода работают. Есть и третий бескомпромиссный вариант, но это уже уровень дата-центра: сделать всё и сразу (дорого, богато и много).  

А как сделать лучше вам? Это можно определить только комплексной оценкой проекта. Факторов очень много: от бюджета и количества системных администраторов нужной квалификации в штате (и на рынке труда в вашем городе) до локации, где оборудование нужно разместить, — геораспределение туда же.

Как только вы опишите проект, всё учтёте, ответ придёт сам собой. Возможно, у вас много места под серверы, просторное и холодное помещение и с десяток админов в штате — тут можно попробовать и количеством взять. Или, напротив, у вас один админ и одна стойка 42U — здесь я бы подумал о дорогом компактном варианте. Но, конечно, каждый случай надо рассматривать отдельно.

Если понадобится помощь в этом непростом деле, в том числе оценить количество и комплектацию оборудования — пишите или звоните. Наши менеджеры уже работали с ВНС и подбирали клиентам решения конкретно под их бюджет, требования и задачи.

Конфигурация серверов для высоконагруженных систем: на что ориентироваться

Если вы решили самостоятельно подбирать серверы и комплектующие для построения ВНС, то нужен ориентир. Точные параметры, вроде количества ядер, скорости сети, объёма памяти и хранилища, зависят от индивидуальных требований, поэтому их я озвучить не смогу. 

Но я перечислю характеристики, к которым нужно стремиться, что-то вроде путеводных звёзд — от них вы и будете отталкиваться при конфигурировании. Это основа для проектирования ВНС:

• Стабильная работа под обычной и пиковой нагрузкой — система эффективно обрабатывает требуемые объёмы данных и устойчива к пиковым нагрузкам за счёт продуманной архитектуры, балансировки нагрузки, мониторинга и динамического масштабирования; ВНС сохраняет высокую производительность при любых сценариях работы;

• Достаточная пропускная способность — ВНС одновременно обслуживает большое (требуемое) количество пользователей и имеет запас;

• Минимальная задержка — быстрый отклик ВНС даже при большом числе запросов. Но это по требованию, для некоторых систем задержка не всегда критична (например, в аналитических системах, где главное — способность переварить большой объём данных);

• Отказоустойчивость и высокая доступность (уровень резервирования) — ВНС работает почти круглогодично (или столько, сколько требует задача), отказ отдельных компонентов не останавливает работу всей системы и не уменьшает её производительность; все основные компоненты и даже целые узлы (серверы в кластере, СХД, сетевое оборудование) зарезервированы с использованием подходов N+1, N+2, 2N, k из N, а при сбое нагрузка автоматически переключается на оставшиеся в строю узлы.

Возможно обслуживание на горячую (без остановки работы) и/или обслуживание с отключением отдельных узлов кластера — при этом все приложения будут работать в штатном режиме. Но стоит учесть, что абсолютной отказоустойчивости и 100%-ой доступности не бывает — у всего есть предел;

• Масштабируемость — можно увеличивать ресурсы ВНС вертикально (объём хранилища, память, менять процессоры на более мощные) и горизонтально (добавлять новые узлы в кластер), в том числе без остановки работы;

• Балансировка нагрузки — ВНС должна разделять входящие запросы между узлами кластера, чтобы равномерно задействовать доступные ресурсы (а не так, что один сервер загружен на 90%, а другой на 10%). Балансировка бывает на трёх уровнях: сетевая (несколько серверов отвечают за один IP-адрес), транспортная (запрос от пользователя направляется балансировщиком на какой-то конкретный сервер, где и обрабатывается) и прикладная (этакий смарт-прокси, когда балансировщик анализирует запросы и направляет их на оптимальные серверы).

• Персонал — без квалифицированных специалистов ничего работать не будет. И важно, чтобы персонал был доступен локально в городе, где ВНС размещена, а не только удалённо или на аутсорсе.

• Комплектующие на замену — доступность оборудования и комплектующих на рынке (как и запасы на собственном складе) архиважны: что-то неизбежно будет выходить из строя, а ВНС строится, как правило, на стандартных конфигурациях — это значит, что замена комплектующих и узлов без лишних телодвижений возможна только на аналогичные решения. Поэтому редкое и узкоспециализированное железо — не лучший вариант для ВНС. Плюс можно попасть в зависимость от конкретного производителя или проприетарной технологии. Эти и сопутствующие риски нужно оценить до закупки оборудования и построения высоконагруженной системы.

Есть и другие характеристики, но это основные. Их можно использовать комплексно (всё и сразу), можно частями (например, если огромная производительность не нужна), можно некоторые с нюансами (например, после отказа одного из серверов в кластере приложения и пользователи переезжают не мгновенно, а с некоторой задержкой: секунды или минуты). 

И да, не все из них обязательны, чтобы создать высоконагруженную систему, так как понятие это гибкое и для всех оно уникальное. Каждый бизнес подбирает характеристики ВНС исходя из критичности бизнес-процессов; из возможной стоимости простоя этих процессов; из бюджета (совокупная стоимость владения, окупаемость и прочее), компетенций персонала и т.д. 

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

Размещение оборудования: дата-центры или серверные, RTO и RPO

Как бывает, когда не изучил местность для дата-центра.

Опять же, место, где высоконагруженная система будет работать — вопрос персональный. Исходя из бизнес-задач составляются технические требования к ВНС, а уже из них принимают решение: что, как и где размещать.

В общем и целом есть два варианта: размещение в собственной инфраструктуре (локально в серверной комнате или в своём ЦОДе, если такой имеется или планируется) или услуга колокейшн в коммерческом дата-центре (сторонние провайдеры, предлагающие пространство для серверов, часто с дополнительными услугами, вроде резервного питания и быстрой сети). Есть, конечно, гибридные схемы или вовсе облачные, но это уже IaaS (Infrastructure as a Service) — в контексте статьи рассматривать не будем.

Чтобы построить систему самому, можно использовать принцип «сверху вниз» — от общего к частному. При этом важно учитывать проблемы на нижнем уровне, чтобы компенсировать их на верхнем, ведь нередко нужных аппаратных решений и правильного места для размещения оборудования нет (или нет бюджета). В таком случае можно нивелировать часть проблем программной архитектурой — а отказоустойчивость и защиту улучшить на более высоких уровнях. Архитектура системы должна решать бизнес-задачи, а не строиться по строгим книжкам — всегда есть несколько подходов к её построению.

Для максимальной отказоустойчивости ВНС создают геораспределенные кластеры — это может спасти даже от локальных катастроф, вроде пожаров, потопов и дронов. Но это крайне дорогой вариант, который не имеет смысла без строгих RTO и RPO (Recovery Time Objective — допустимое время простоя и восстановления системы; Recovery Point Objective — максимально допустимый объём данных, который можно потерять, выраженный во времени). 

Если RTO равен, например, 2 часам, то это значит, что от критического сбоя в системе до полного восстановления должно пройти не больше 2 часов. Если же RPO равен 2 часам, то значит, что целевая точка восстановления должна создаваться каждые 2 часа. Например: последняя резервная копия системы была сделана в 23:00, а сбой случился в 00:00; при RTO и RPO в 2 часа вы должны успеть восстановиться до 02:00 к точке в которой система была в 23:00.

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

 Колокейшн в коммерческом ЦОДе по умолчанию дороже, но надёжнее.

Однако при проектировании ВНС нужно учитывать не только технические, но и бизнес-риски. Например, в коммерческий ЦОД могут прийти с конфискацией серверов, и вероятность этого может быть выше, чем вероятность затопления собственного подвала с верной охраной :)

Чтобы принять решение о размещении, вам нужно:

1. Идентифицировать риски: Перечислить все потенциальные угрозы (затопление, пожар, конфискация, атаки на канал связи и т.д.).

2. Оценить вероятность и последствия: Понять, какова вероятность срабатывания каждого риска и к каким финансовым или репутационным потерям он приведёт.

3. Разработать способы митигации: Например, резервные копии данных вне зоны риска, распределённые кластеры для защиты от локальных катастроф, работа с юридической безопасностью при размещении оборудования в ЦОДе.

4. Решить, что митигация оправдана, а что можно принять как допустимый риск:

1. Для крупных систем с высоким SLA митигация рисков — необходимость.

2. Для небольших компаний, например, магазина офисных стульев с сайтом-визиткой, такие риски могут быть минимальны и прорабатывать их нецелесообразно.

Поэтому при выборе между локальным и внешним размещением не забывайте, что отказоустойчивость — это не только о технике, но и о стратегическом управлении рисками. Только оценив все аспекты, вы сможете подобрать оптимальное решение для вашего бизнеса.

Домены сбоя и единая точка отказа: failure domain и SPOF

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

Хочу немного подробнее остановиться на этом моменте, так как отказоустойчивость и домены сбоя идут вместе рука об руку. Нам важны 3 понятия:

1. Единая точка отказа (Single Point of Failure, SPOF) — это конкретный компонент системы, отказ которого приведёт к полной остановке работы всей системы. Важно, что это критический элемент, у которого нет резервирования (либо невозможно зарезервировать, либо не сделали).

Пример в ВНС: один источник питания для двух серверов. Если он выходит из строя, серверы станут недоступны.

Чем меньше единых точек отказа, тем надёжнее ВНС. SPOF находится внутри домена сбоя.

2. Домен сбоя (failure domain) или домен единичного отказа — это область системы, в пределах которой сбой одного элемента (SPOF) может привести к выходу из строя всех связанных с ним компонентов.

Пример в ВНС: 4 сервера с единым источником питания в стойке — они находятся в одном домене сбоя, так как отказ этого источника приведёт к недоступности всех 4 серверов.

Внутри домена сбоя может быть несколько SPOF’ов, например коммутатор и система хранения данных для двух серверов.

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

3. Домен двойного отказа (Double Fault Domain) — это концепция в архитектуре отказоустойчивых систем, которая описывает ситуацию, когда сбой двух независимых, но критически важных компонентов приводит к отказу всей системы или значительного её участка.

Пример в ВНС: две независимые стойки серверов, каждая со своим питанием. Если одновременно произойдёт пожар в одной стойке и сбой питания в другой, система не сможет работать.

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

Пример отказоустойчивости для домена двойного отказа низкого уровня: RAID-6, который выдерживает сбой двух дисков одновременно.

Подытожу таблицей.

Краткий подытог — и про вторую часть

Высоконагруженная собака несёт вторую часть статьи.

В первой части мы прошлись по основным понятиям и затронули аппаратную часть ВНС: какое оборудование использовать; на что ориентироваться при подборе конфигурации; какие есть варианты по размещению этого добра; что может стать точкой отказа и т.д. 

Да, в каждый пункт можно углубляться с подробностями, но формат статьи для этого не подходит. Нужен минимум лонгрид по каждой теме, а то и книга небольшая. Так что если возникнут вопросы, задавайте их в комментариях под этой статьёй, а для реальных проектов можно сразу связаться с менеджерами Сервер Молл — ребята подскажут и подберут всё в лучшем виде.

Спасибо, что дочитали! В следующей статье я расскажу про программную часть в архитектуре высоконагруженных систем: мониторинг и протоколирование, балансировка нагрузки, кэширование, базы данных, очереди сообщений, микросервисная архитектура, CDN, резервирование данных, кластеризация, техники восстановления после сбоев и многое другое! 

Чтобы не пропустить, подписывайтесь на наш Telegram и новостную рассылку в поле ниже :)