Андрей Гордиенко

Привет! На связи Андрей Гордиенко, ведущий специалист по направлению поддержки облачных продуктов в Selectel. Наша команда следит за своевременными обновлениями, постоянно заботится о состоянии системы, а в случае необходимости готова оперативно выполнить восстановительные работы. Напомню, что подготовил материал, состоящий из трех частей. Цель — помочь всем, кому необходимо разбираться в особенностях взаимодействия распределенных сервисов. Рассказываю, как использовать сети для выстраивания новой инфраструктуры или улучшения существующей. Предыдущие статьи: Как настраивать сети: определения, типовые схемы, особенности Как настраивать сети: выделенный и облачный серверы Эта часть — заключительная. В ней погрузимся в работу готовых решений. Немного теории и практики помогут понять, что может пойти не так в том или ином случае. Иногда клиенты, когда самостоятельно добавляют услуги, не до конца понимают все особенности сетевых настроек, а что самое печальное — не документируют параметры сети. После перезагрузки оказывается, что их сервисы должным образом не взаимодействуют. Сегодня на примерах посмотрим, как делать решения отказоустойчивыми. Общие понятия Готовые решения — услуги, в рамках которых Selectel берет на себя полную ответственность за бесперебойную работу как инфраструктурной части, так и необходимого ПО. Не беспокоясь о функционировании того или иного сервиса, наши клиенты полностью сосредотачиваются на разработке. Им не приходится тратить ресурсы на побочные процессы — например, на покупку и обслуживание оборудования, обновления и вопросы совместимости. Так они не только существенно экономят время и средства, но и избегают множества потенциальных проблем. Архитектура Kubernetes предполагает разделение на мастер-ноды, осуществляющие управление кластером, и воркер-ноды, на которых разворачиваются пользовательские приложения. Для баз данных более привычны термины «мастер» и «реплика». В OpenSearch используется своя система мастера и реплики, в которой информация дублируется сразу на все узлы кластера. Отказоустойчивость в Kubernetes обеспечивается за счет перенаправления трафика на исправную мастер‑ноду. Файловое хранилище не имеет встроенного механизма резервирования — его обеспечивает Selectel путем тройной репликации в разных дата‑центрах. Доступ к общему файловому пространству осуществляется благодаря управляющему серверу. При подключении любой из вышеперечисленных услуг сетевые параметры, определенные клиентом, автоматически распространяются на все задействованные ноды — притом, что прямого доступа к ним у заказчика нет. В прошлой статье мы рассматривали примеры как ручной, так и автоматической настройки. Тогда использовался стенд, на котором размещались два облачных сервера и один выделенный — все с разными сетями. Параметры облачных серверов задавались автоматически, а выделенного — вручную, в файле конфигурации интерфейса. Шлюз одного облачного сервера направлялся на глобальный роутер, а шлюз второго — на облачный, причем для обеспечения сетевой связности требовалось прописывать статические маршруты. Все самое важное происходило как раз на втором облачном сервере. На нем тогда и тренировались автоматически настраивать маршруты, шлюз и прочие параметры — как при создании самого севера, так и в процессе его эксплуатации. Но что произойдет при изменении настроек в карточке сети панели управления? Что будет, если перезагрузить сервер? Корректировка настроек в карточке сети сама по себе не отражается на сервере немедленно. Однако при его перезагрузке, параметры из карточки применятся и перезапишут все сетевые настройки, сделанные вручную. В каких случаях такой подход оправдан, а в каких нет? Предположим, клиент когда‑то самостоятельно настроил и не задокументировал сетевое взаимодействие компонентов своего сервиса. Очевидно, что изменение параметров в карточке приведет к сбою после перезагрузки серверов. Избежать этого можно, только отключив cloud-init — утилиту для автоматической инициализации облачных экземпляров при их запуске. Такой случай мы рассматривать не будем, он чреват неожиданностями. Другое дело — готовые решения. Здесь сетевая связность, как и остальная функциональность, обеспечивается провайдером. Задание параметров сети через настройку в карточке — естественный подход и единственно надежный способ взаимодействия компонентов. Разработчики активно добавляют такую функциональность к готовым сервисам. Сейчас уже есть возможность на лету применять новые сетевые настройки для файлового хранилища и балансировщика нагрузки. Применение на практике Несколько слов о резервировании Продолжим рассматривать пример из предыдущей статьи про настройку одного выделенного и двух облачных серверов. Как и у первого из них, некоторые готовые решения настроены по умолчанию на шлюз глобального роутера. Другие же потребуют интернет, как и второй сервер. Рассмотрим первое готовое решение, которое позволяет не только объединить общие для всех серверов данные, но и позаботится о целостности информации. Для резервирования и хранения данных Selectel предлагает несколько услуг. Объектное хранилище для неограниченного объема неструктурированных и полуструктурированных данных. Поддерживается доступ через Amazon S3 API и OpenStack Swift API. Данные можно автоматически копировать в облако с помощью настроенного скрипта или вручную с помощью инструментов. Доступны функции версионирования и установки лимитов для автоматической очистки контейнеров и хранения версий данных. Резервное копирование Veeam — коробочное решение с готовыми лицензиями и местом под хранение данных в РФ, что важно для некоторых тендеров. Файловое хранилище — предназначено для долговременного хранения и организации данных, структурированных на уровне файлов. Его сейчас и рассмотрим подробнее. Файловое хранилище Файловое хранилище сегодня доступно как в локальной, так и в публичной сети. При использовании внешней сети, пожалуй, наиболее важный параметр — разрешенные IP-адреса для подключения. Локальная связность имеет ряд тонких настроек, поэтому именно ей уделим больше внимания. Selectel ограничил доступ к хранилищу с портов, не относящихся к работе протоколов NFSv4 и CIFS SMBv3, чтобы максимально обезопасить данные клиентов от внешнего злонамеренного воздействия. Также предусмотрена ручная настройка разрешений для доступа с определенных IP-адресов как в локальной, так и во внешней сети. Ниже — скриншот с правилами. Хотелось бы отметить, что использование публичной сети нежелательно при работе с хранилищем внутри инфраструктуры Selectel. Внешние интерфейсы могут существенно ограничить производительность ваших сервисов — их пропускная способность значительно ниже. На выделенных серверах скорость обмена данными определяется физическими возможностями сетевой карты — примерно 1 Гбит/с. Для облачных серверов лимит устанавливается программно и только начинается с 1 Гбит/с — ускорение производится по запросу в тикет‑систему. Также стоит учитывать тарификацию трафика. Обмен данными в облаке Selectel бесплатен. Для выделенных серверов лимит хоть и немаленький, но его все же лучше расходовать на другие цели. Внешний доступ часто используют для резервирования данных в нескольких дата‑центрах. Например, файловое хранилище на HDD даст значительное пространство по привлекательной цене — 160 ₽ за 100 ГБ, на момент написания статьи. Такой доступ к хранилищу с внешних площадок окажется и безопаснее, и экономичнее. Локальная сеть Взаимодействие с файловым хранилищем из публичной сети никаких сложностей не несет, поэтому уделять внимание этому вопросу не будем. Работу же в локальной сети рассмотрим подробнее. Для примера разместим файловое хранилище в ru-2 — эту зону доступности в предыдущих статьях мы еще не использовали. Тем самым организуем георезервирование между сервисами в инфраструктуре: серверы работают в одном пуле, а данные хранятся в другом. Это хороший вариант, и его можно использовать в продакшн. Однако следует учитывать, что между Москвой и Санкт-Петербургом отклик выше, чем внутри одного региона. Условно архитектура файлового хранилища выглядит следующим образом: Вначале мы говорили, что в каждом готовом решении есть управляющая прослойка, которая работает на отдельном облачном сервере. На схеме выше видно, что существует сервер (на нем развернуто специализированное ПО), который обслуживает общий доступ к подключенным дискам. Схема сети. Смысл файлового хранилища — в создании отказоустойчивой масштабируемой файловой системы для хранения данных. Подключить его можно практически ко всем услугам и продуктам Selectel. Исключения: балансировщики и сервисы, не работающие с внешними данными, а также СУБД и объектное хранилище, которые и сами являются хранилищами. Кроме того, у клиентов нет доступа к управлению составляющими кластера, что исключает возможность настройки программного обеспечения внутри них. Разберем особенности устройства сети файлового хранилища. Главная из них — в том, что оно всегда должно работать с глобальным роутером. Условие необязательное для самого сервиса, но важное для демонстрации нюансов настройки сети. Услуга должна быть доступна на всех сервисах. Даже если это не требуется, можно просто не подключать хранилище к участникам глобального роутера, но саму сеть в глобальном роутере все‑таки создать крайне полезно. Таким образом, мы сможем пользоваться общими данными и на выделенном, и на облачных серверах. Напомню, основная цель этого цикла статей — масштабирование от выделенного сервера в отказоустойчивую среду. Сервис хранилища позволяет не только использовать общие скрипты или данные, но и работать с резервными копиями. При необходимости можно создать несколько хранилищ под разные цели. В случае выходе сервера из строя получится развернуть новый и без труда восстановить данные. Сейчас мы пойдем слегка по ложному пути и кое-что сделаем неправильно. Подобный подход к изложению может показаться странным. Однако так мы избавимся от самой частой ошибки большинства клиентов, которые используют гибридную инфраструктуру. К тому же такой взгляд позволит нам лучше понять суть работы с сетями и в Selectel, и, скорее всего, у других операторов. Что происходит обычно Заказывается несколько услуг в одной сети — и это выглядит логично, потому что экономится адресное пространство и упрощается схема. Однако всплывает проблема… Не учитывается, что услуги работают по‑разному и требования к сети у них тоже разные. Такая поверхностность закладывает непредвиденные ошибки в перспективе. В какой‑то момент для подключения новых услуг требуется вносить изменения в карточку сети. Так заведомо внедряется ошибка в работу услуг, которые были добавлены ранее. Однажды все эти забытые особенности работы сети различных услуг проявляют себя. В результате «прод лежит» и требуется общение с отделом поддержки. Итак, начнем поэтапно добавлять услуги — именно так, как это обычно и происходит. Как ни странно, все идет достаточно гладко. Но это до тех пор, пока мы не внесем каких-либо изменений и не произойдет обновление, требующее перерыва связи в сервисе. Обратите внимание: сам процесс подключения услуг описан верно — с описанием всех особенностей и требований. Ошибка тут, по сути, одна — о ней в конце статьи (скорее всего, вы и так догадаетесь). Перед заказом услуги создадим сеть в глобальном роутере. Добавить ее можно и позже, есть специальная инструкция. Сеть отмечена курсором. Название — K8s, так как будем использовать ее для Kubernetes. Подобные параметры мы уже видели. Замечу, что это карточка сети, созданная внутри глобального роутера, а шлюз — его IP‑адрес. В карточке облачной платформы шлюз сети также указывает на глобальный роутер — так сервер, обслуживающий файловое хранилище, получит все маршруты до смежных сетей, причем без дополнительных манипуляций. Такой способ мы исследовали на примере первого облачного сервера во второй части, то есть Default — 10.10.10.254. Проверим работу на выделенном сервере, предварительно не забываем добавить нужные маршруты согласно схеме сети. На физических серверах потребуется ручная настройка. Действия ниже зависят от операционной системы, в нашем случае — Ubuntu 20. Так как используется netplan, изменения будем вносить в его конфигурационный файл /etc/netplan/50-cloud-init.yaml: Нас интересуют строки в разделе «routes:». Видно перечень всех сетей, которые использовали в двух предыдущих частях и планируем задействовать сейчас. Мы заранее занесли их в схему — это правильный подход перед постройкой инфраструктуры с запасом на будущее. Проверим маршруты: root@Boole:~# ip r default via 212.41.13.1 dev eth0 proto static 10.0.0.0/24 via 172.22.10.1 dev eth1 proto static 10.10.10.0/24 via 172.22.10.1 dev eth1 proto static 172.22.10.0/24 dev eth1 proto kernel scope link src 172.22.10.2 192.168.0.0/24 via 172.22.10.1 dev eth1 proto static 192.168.100.0/24 via 172.22.10.1 dev eth1 proto static 212.41.13.0/24 dev eth0 proto kernel scope link src 212.41.13.141 Заказываем услугу файлового хранилища: На скриншоте — выбрано название, объем хранилища, сеть. IP‑адрес получаем автоматически из свободных или задаем вручную. Протокол — NFSv4. Сейчас важно понять, что будет происходить при создании сервиса. Еще раз: файловое хранилище — облачный сервер с дисками. Заказы этих услуг тоже очень похожи: выбираются параметры, сеть. Так же, как и при создании облачного сервера, отработает утилита cloud-init. Ее задача — сравнить параметры в свойствах сети, которые определены заранее в карточке и прописать их в конфигурации сервера. Теперь подключаем хранилище к выделенному серверу. Все требуемые действия, в том числе установка необходимых утилит, описаны в инструкции. Команда отображается в карточке самой услуги: sudo mkdir -p /mnt/nfs && sudo mount -vt nfs "10.10.10.100:/shares/share-db6544c3-e12f-4e0c-a8da-1e88c25cdf0f" /mnt/nfs mount.nfs: timeout set for Fri Apr 25 09:38:03 2025 mount.nfs: trying text-based options 'vers4.2,addr10.10.10.100,clientaddr172.22.10.2' Для проверки работоспособности хранилища создадим произвольный файл. Напомню, что ping и прочие сетевые утилиты нам не помогут — любой посторонний доступ заблокирован. Остается простой способ — создаем файл в хранилище: # Создаем файл: root@Boole:~# fallocate -l 10M daygeek.txt # Копируем файл в ранее смонтированную директорию. Процедура монтирования есть в команде подключения файлового хранилища (начинается с sudo mount): root@Boole:~# cp daygeek.txt /mnt/nfs/ # Проверяем содержимое каталдога: root@Boole:~# ls -lh /mnt/nfs/ total 10M -rw-r--r-- 1 root root 10M Oct 22 18:07 daygeek.txt Файловое хранилище примонтировалось — это видно по выводу команды: mount.nfs: timeout set for Fri Apr 25 09:38:03 2025 mount.nfs: trying text-based options 'vers4.2,addr10.10.10.100,clientaddr172.22.10.2' Файл добавился в каталог. Теперь примонтируем его же на облачный сервер. Монтируем файловое хранилище к облачному серверу той же командой, что и ранее: sudo mkdir -p /mnt/nfs && sudo mount -vt nfs "10.10.10.100:/shares/share-db6544c3-e12f-4e0c-a8da-1e88c25cdf0f" /mnt/nfs Получаем сообщение об успешном выполнении и проверяем наличие файла: root@server-ru-9:~# ls -lh /mnt/nfs/ total 10M -rw-r--r-- 1 root root 10M Oct 22 15:07 daygeek.txt Доступ есть, все в порядке. Вы, наверное, заметили схожесть в работе с первым облачным сервером. Файловое хранилище так же самостоятельно получает все настройки из карточки сети, включая указание шлюза по умолчанию для соединения с глобальным роутером. Доступ ко всем участникам сети получен автоматически без каких-то дополнительных вмешательств. Подход к работе с выделенным сервером отличался разительно: он настраивался полностью вручную. Итак, вся сеть доступна, серверы видят общий файл. Теперь усложним схему. K8s Managed Kubernetes упрощает процесс развертывания, масштабирования и обслуживания контейнерной инфраструктуры. Selectel отвечает за обновление версий, безопасность и работоспособность Control Plane Kubernetes. Чтобы управлять кластером, нужно подключиться к специальному адресу API. Для этого существуют различные программы — например, kubectl. Клиент создает отдельный манифест (или манифесты) и применяет их к кластеру — так и происходит его настройка. Давайте теперь рассмотрим схему работы Kubernetes и включим в нее функционирование сети. Состав кластера. Попытаемся взглянуть со стороны инфраструктуры. В центре Kubernetes поднимается некая управляющая прослойка для работы кластера — мастер‑нода. Их может быть и несколько, если мы хотим повысить надежность проекта. Чем больше мастер‑нод — тем выше отказоустойчивость. В панели управления, при заказе услуги Managed Kubernetes, видим такое понятие, как «Группа нод» — это набор идентичных серверов, они будут одинаковые в каждой группе, хотя сами они обычно отличаются. В итоге имеются следующие компоненты: мастер-ноды (одна или несколько) — обычные серверы с установленным серверным ПО Kubernetes; клиент не имеет к ним доступа ни при каких обстоятельствах, а для получения информации от этих серверов он должен обратиться в службу поддержки; группы нод (они же воркер‑ноды) — обслуживают ПО клиента, а он к ним имеет прямой доступ и возможность размещать свои данные. Немного остановимся на этом моменте. Объясню, почему мы дали клиенту больше прав на воркер нодах. На это есть несколько причин. Кластер K8s всегда отслеживает доступность собственных нод. Если на одной из них что‑то пойдет не так, он перезапустит ее и вернет к состоянию на момент применения последнего манифеста. То есть видимость того, что клиент может что‑то сделать с воркерами, обманчива — мы все равно ему не дадим сломать кластер. В определенное клиентом время в Selectel резервируется окно обслуживания. В этот период проводятся работы с мастер‑нодами: приходят обновления и закрываются другие задачи. Откатываются все изменения на воркер-нодах на момент применения последнего манифеста. Если клиент зашел на кластер, перенастроил как‑то сеть или добавил внешний адрес для ноды — все будет отключено и возвращено обратно. То есть рано или поздно все воркер‑ноды все равно вернутся в состояние в соответствии с манифестами. Посмотрим на схему работы кластера K8s с двумя роутерами: Обратите внимание, что кластер работает в связке с облачным роутером и это обязательное условие. На иллюстрации выше IP‑адреса приведены для примера, далее будет представлена рабочая схема с действующими сетями. Важный момент: для доступа услуги к другим сервисам кластеру требуется прописать маршруты из-за использования облачного роутера. В отличие от файлового хранилища, где шлюз по умолчанию направлен на глобальный роутер, для кластера K8s шлюз по умолчанию должен быть направлен на облачный роутер — так обеспечивается доступ во внешнюю сеть, что обусловлено архитектурой услуги. Добавление услуги Kubernetes в нашу сеть Предположим, что необходимо обеспечить не только базовое резервирование и отказоустойчивость, которые были реализованы ранее с помощью геолокации и других инструментов. Требуется также высокая доступность с автоматизированным обслуживанием инфраструктуры — например, с гарантией SLA 99,9%. Для этого как нельзя лучше подходит Kubernetes. Кластер K8s можно развернуть и самостоятельно, не прибегая к готовым решениям. Однако для его обслуживания потребуется администратор. Мы в Selectel в рамках Managed Kubernetes берем на себя сопровождение инфраструктуры и своевременное обновление программного обеспечения — клиенты могут сосредоточиться исключительно на разработке. Кластеры K8s вызывают отдельный интерес, так как их требования к сети в чем‑то противоположны критериям для файлового хранилища. Именно поэтому я добавлю кластер рядом с файловым хранилищем — чтобы продемонстрировать частую ошибку. В то время как для баз данных и файлового хранилища доступ в публичную сеть не обязателен и предоставляется только при работе с внешними площадками, для кластеров K8s такой доступ необходим. Без него невозможны обновления, существенные для безопасности, и обслуживание для корректной работы. Случись такое, клиентам, скорее всего, придут тикеты с просьбой пересоздать кластер с правильными параметрами сети. Важно: сейчас речь не о внешнем адресе управления кластером API (это условие не обязательное), а о наличии выхода во внешнюю сеть внутри локальной. Перейдем к практике и попытаемся создать кластер. Сразу возникнет ошибка, так как ему требуется интернет-соединение. Ошибка: «Эта подсеть не подключена к роутеру». Приостановим создание кластера и перейдем к подготовке сети. Подключим ее по инструкции к облачному роутеру. Использовать будем IP‑адрес 10.10.10.1 — это облачный роутер. Для того, чтобы Default на кластере k8s был направлен на облачный роутер, его необходимо поменять в карточке сети, а также подключить к нему сеть. Ранее Default был 10.10.10.254 — редактируем карточку и используем 10.10.10.1. Все необходимые подробности — в документации по настройке связности между кластером на облачном сервере с другими сервисами. Добавляем маршруты, но не все. Объединяем кластер только с выбранными серверами. Обратите на это внимание, так как мы вернемся к теме позже и увидим, почему это важно. Добавляем для сети 10.10.10.0/24 маршрут 172.22.10.0/24 nexthop 10.10.10.254. Кластер будет знать, где размещена сеть 172.22.10.0/24, а именно на 10.10.10.254. Если запрос поступит на другую сеть, поиск будет осуществляться по IP-адресу Default, который перенаправлен на облачный роутер. В результате доступ не будет предоставлен. Настройка кластера Если вы обратили внимание, я всегда предварительно подготавливаю сеть перед развертыванием сервиса. Дело в том, что после его создания изменить что‑то будет невозможно без обращения в поддержку. На сегодняшний день функционал панели управления расширяется, а в момент написания статьи файловое хранилище и балансировщики уже могут применять новые параметры сети без пересоздания сервиса. Ошибок с сетью больше нет, создание кластера не вызовет проблем. Если не поменять шлюз в свойствах сети, то кластер создастся, но придет тикет с просьбой исправить ситуацию, так как его не получится обслуживать. Рассмотрим подробнее процедуру создания кластера. Мастер-нода — это облачный сервер, на котором работает серверная часть K8s (как было выяснено ранее). Создается он с параметрами, указанными в карточке сети. Процесс аналогичен поднятию второго облачного сервера из предыдущей части, где в карточке сети указывались дополнительные маршруты и было показано, как они отражаются внутри сервера. Точно также и сервер Kubernetes получает Default на облачный роутер, а дополнительные маршруты — из свойств сети. После создания кластера мы видим воркер-ноды. В карточке сети, в разделе Порты, отображается IP-адрес мастер-ноды. Теперь проверим доступ к услугам Kubernetes и файловому хранилищу с выделенного и облачного серверов. Напомню, задача состояла в том, чтобы предоставить доступ не ко всей сети, а только к избранным услугам — в нашем примере выделенный сервер. С выделенного сервера доступ есть: root@Boole:~# ping 10.10.10.194 PING 10.10.10.194 (10.10.10.194) 56(84) bytes of data. 64 bytes from 10.10.10.194: icmp_seq1 ttl62 time12.0 ms 64 bytes from 10.10.10.194: icmp_seq2 ttl62 time9.10 ms ^C --- 10.10.10.194 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev 9.100/10.561/12.022/1.461 ms С облачного сервера доступа нет: root@server-ru-9:~# ping 10.10.10.194 PING 10.10.10.194 (10.10.10.194) 56(84) bytes of data. ^C --- 10.10.10.194 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2045ms Задача состояла в том, чтобы добавить маршрут к сети, предоставляющий доступ только выделенному серверу. Для этого мы изменили шлюз по умолчанию с глобального роутера на облачный, открыв кластеру доступ к внешней сети. Чтобы обеспечить доступ к локальной сети, мы добавили только один маршрут к одной сети. Облачная платформа в ru-9 не была включена в этот список. Это может быть полезно, если требуется ограничить или разрешить доступ к определенным сегментам. Продолжим наше исследование. В этой сети, как мы помним, функционирует файловое хранилище. С кластером K8s оно использует ту же сеть. Однако, в отличие от кластера K8s, файловое хранилище было создано до внесения изменений в карточку сети. Проверим, работает ли файловое хранилище. Загрузим новый файл: root@server-ru-9:~# fallocate -l 10M testfile.txt root@server-ru-9:~# mv testfile.txt /mnt/nfs/ root@server-ru-9:~# ls -lh /mnt/nfs/ total 20M -rw-r--r-- 1 root root 10M Oct 22 18:45 daygeek.txt -rw-r--r-- 1 root root 10M Oct 22 19:17 testfile.txt Теперь удостоверимся в доступности файла и убедимся в работе выделенного сервера: root@Boole:~# ls -lh /mnt/nfs/ total 20M -rw-r--r-- 1 root root 10M Oct 22 21:45 daygeek.txt -rw-r--r-- 1 root root 10M Oct 22 22:17 testfile.txt Все превосходно работает. Напомню, что проверку приходится выполнять таким образом потому, что большинство протоколов и портов хранилища заблокированы по соображениям безопасности — ping до IP‑адреса хранилища не пройдет. В предыдущей части, когда мы экспериментировали с облачными серверами, при изменении настроек сети тоже ничего не происходило… ровно до перезагрузки сервера. Все благодаря cloud-init — утилите, которая на старте системы срабатывает и восстанавливает параметры сети. Устроим то, что обычно все и делают, когда хранилище заканчивается — увеличим его, скажем, на 10 ГБ. Увеличение объема инициирует «приращение» диска на виртуальной машине, которая обслуживает сервис. Она перезагружается, а вместе с ней применяются новые параметры сети. Проверяем доступность снова. Выделенный сервер: root@Boole:~# ls -lh /mnt/nfs/ total 20M -rw-r--r-- 1 root root 10M Oct 22 21:45 daygeek.txt -rw-r--r-- 1 root root 10M Oct 22 22:17 testfile.txt Облачный сервер: root@server-ru-9:~# ls -lh /mnt/nfs/ Как и ожидалось… содержимое каталога не отображается. Изменилась конфигурация файлового хранилища (увеличился размер диска) — сервер потребовал перезагрузки — все параметры, прописанные в карточке сети, во время запуска подтянулись в сетевой интерфейс. Наша команда активно размышляет над тем, как упростить жизнь администраторам, которые конфигурируют сеть неочевидными способами и никак не документируют свои настройки. Например, появилась кнопка Обновить настройки сети. Скажем, решение проблемы из последнего примера — это вернуть Default на 10.10.10.254, нажать кнопку Обновить настройки сети, далее — дождаться возобновления работы услуги и восстановить все обратно, чтобы кластер не отвалился при следующих обновлениях и перезагрузках. Итак, мы создали достаточно отказоустойчивую инфраструктуру: распределили группы нод по разным пулам, защитились от сетевых ошибок и неполадок в стойках с железными хостами виртуализации. Можем задействовать балансировщик нагрузки и распределять запросы. Ничто не мешает бесконечно совершенствовать и масштабировать проект, разбивать его на отдельные сегменты, подключать сетевые экраны и так далее. Базы данных Сеть базы данных работает по такому же принципу, как и файловое хранилище. Можно использовать сервис как внутри локальной, так и во внешней сети. Не будем останавливаться, все подходы — идентичны хранилищу. Единственное — обозначим принцип работы и в каких случаях услуга востребована. Есть несколько вариантов конфигураций: обычная, без резервирования; отказоустойчивая, с репликами. Выбор зависит от того, насколько критичен простой при аварии. Если бизнес набрал обороты и приносит доход, то нет смысла экономить на стабильности. Вообще, «безопасности много не бывает». Кластеры БД — это высокопроизводительная инфраструктура для обработки больших массивов данных. Облачные БД — сервис для развертывания и управления быстрыми и отказоустойчивыми кластерами поддерживаемых СУБД в облаке. Услуга, как и кластер Kubernetes, будет иметь управляющую прослойку — мастер, где развернуто программное обеспечение для работы с базами данных. Мастер резервируется slave-нодами. Каждому серверу назначается IP-адрес (локальный или публичный) и общий домен для подключения. Подключение осуществляется к любому IP-адресу (мастера или slave-ноды), либо по домену, что повышает отказоустойчивость. Подробнее о подключении рассказывается в документации облачных баз данных. В отличие от кластеров K8s, в случае баз данных нет доступа ни к мастер, ни к слэйв, так как любые изменения в работе ПО сервиса критичны. Исправить ошибки в кластере K8s нетрудно, так как откат конфигурации ничему не повредит и приложения продолжат функционировать. С базами данных все иначе: Selectel хранит информацию и отвечает за ее целостность. Исправление ошибки Итак, мы используем глобальный роутер и нам необходимо обеспечить доступ ко всем услугам в локальной сети. Для этого выбираем вариант настройки, когда Default маршрута указывает на глобальный роутер, и предоставляем доступ к кластеру всем участникам. Если нужно, то ограничить доступ можно либо маршрутизацией на самих участниках сети, либо прописав отдельные маршруты в карточке (как в K8s). Именно эта идея приводит нас к «правильному решению». Завершим статью исправлением той самой ошибки работы кластера K8s и файлового хранилища. Основная мысль: перенос каждой из услуг в отдельную сеть, причем неважно, в рамках одной зоны доступности они будут или разных. Проще всего будет выполнить перенос файлового хранилища. Достаточно создать новое и переместить файлы, примонтировав хранилища в разные каталоги. Так и поступим: создадим новое в ru-3, после чего старое в ru-2 удалим. Получим изначально задуманную конфигурацию. Каждая услуга — в своей зоне и со своей адресацией. Итак: одна сеть работает исключительно с выделенными серверами; другая — только с облачными; если используется множество зон, для каждой — отдельная сеть; файловое хранилище также работает в отдельной сети, которую мы можем как сделать доступной для всех, используя Default глобального роутера, так и закрыть с помощью статических маршрутов; K8s работает в отдельной сети, в которой мы также можем регулировать маршруты, причем они могут не совпадать с маршрутами файлового хранилища; базы данных также будет иметь и свои маршруты, и свои настройки сети. Каждая услуга имеет свои особенности как в работе сети, так и самого сервиса. Для каждого нового сервиса — будь то база данных, файловое хранилище или кластер K8s — лучше создавать отдельную подготовленную сеть. Если потребуется внести какие‑либо корректировки — они будут относиться исключительно к этой услуге и только для регулировки доступа к другим зонам и сервисам. В конечном результате мы получим схему, о которой говорили в самом начале — в первой части: Каждая сеть размещается в соответствии с первоначальным планом. Это может быть одна зона доступности (если важна скорость доступа между зонами в пределах одного города) или же сервисы могут быть распределены по разным регионам. Суть остается прежней: разные сервисы — разные параметры. К одним из них даем доступ бухгалтеру, к другим — разработчикам. Контролируйте доступ с помощью маршрутов, используя панель управления или OpenStack CLI. Подобная схема, возможно, покажется громоздкой, но она упростит жизнь любого администратора через какое‑то время. Можно возразить и подумать, что предоставление доступа для всех будет ошибочно. В этой статье мы так сделали для файлового хранилища и базы данных. Никаких проблем не предвидится — мы ограничиваем доступ при помощи маршрутов. Маршруты к сервису, доступ к которому не требуется со стороны услуги, следует удалить. Вместо того, чтобы устанавливать Default на глобальный роутер, мы можем управлять доступом на уровне отдельных сетей для каждой услуги. Важно помнить, что ограничение доступа для нескольких услуг приведет к необходимости перезапуска сервера — например, чтобы расширить список доступных сетей. Так, для БД потребуется пересоздание из бэкапа, для файлового хранилища — применение новых параметров, а для K8s — пересоздание кластера и перенос подов. Если мы разместим в одной сети два сервиса, то нам может понадобиться разграничить маршруты, причем добавить для одного из них один комплект, а для второго другой не получится. Вариантов, где что‑то может пойти не по плану, не так уж и много. Главное — вы теперь знаете, что может произойти, в какой момент и почему. Этих знаний достаточно для принятия верного решения при проектировании сети.

Андрей Гордиенко

Материалы автора

Как настраивать сети: готовые решения Selectel для максимальной отказоустойчивости

Облачные роутеры и публичные IP

Выделенный и облачный серверы: создание, настройка, сетевая связность

Основы настройки сети: определения, типовые схемы, особенности