Erase cluster tips что это
Реакция на аварию: растянутый кластер против DR-площадки
У нас есть два подхода к Disaster Recovery: «растянутый» кластер (active-active-инсталляция) и площадка с выключенными виртуальными машинами (репликами). Они имеют несколько точек сохранения снэпшотов.
Запрос на катастрофоустойчивость есть, и многим нашим клиентам это реально нужно. Поэтому мы начали прорабатывать обе схемы в рамках нашего продакшна.
У методов есть плюсы и минусы, сейчас про них расскажу.
«Растянутый» кластер
Как видите, это стандартная история метрокластера. В плюсах — практически нулевой простой, пауза только на время запуска виртуальных машин. Отрабатывает такая фича — VMware High Availability (HA). Она видит, что хосты потерялись, и сразу же перезапускает ВМ на удалённой площадке.
Запуск делается сразу с СХД, которая находится в кластере.
СХД с геораспределённым кластером — это маркетинговая фича NetApp. У других производителей есть нечто с похожим названием. По сути, это продуманная асинхронная репликация с одной стороны на другую. Пишем на одну ноду в локальной сети и синхронизируем через специализированные каналы связи с другой.
В случае отказа одной из СХД оставшаяся (на другой площадке) презентует пути к дискам оставшимся же хостам. На них перезапускаются ВМ, которые погибли. Всё происходит автоматически — ЦОД грохнулся, всё перезагрузилось, СХД отработали, VMware отработала. Клиент увидел, что всё моргнуло и перезапустилось.
Единственное, кэш из оперативной памяти ВМ может потеряться. Но если база данных его скинула, то потеря нулевая по времени.
Если у нас теряется связь между площадками, то всё продолжает работать на своих местах и, как только связь восстанавливается, начинает синхронизироваться.
Минус — высокая цена. Потому что нужна фактически двойная СХД (причём аналогичная по типам, скорости и объёму дисков первой СХД на основной площадке), которую нельзя как-то использовать, кроме как под резерв. Плюс обвязка к СХД для метрокластера, это FC-бриджи, FC-сеть и прочее.
У нас два ЦОДа, между ними FC-связка по двум лучам (четыре линии тёмной оптики и DWDM). Это две железки, каждая обеспечивает по 200 Гбит пропускной способности для FC и Ethernet.
Альтернатива с DR
Есть софт с интуитивно запоминающимся названием — VMware vCloud Availability for Cloud-to-Cloud DR.
Это система создания идентичной ВМ на удалённой площадке раз, условно говоря, в 15 минут. К ней на изоленте примотана система презентации всего этого правильным образом в механизмы управления облаком.
То есть в бэкенде находится технология VMware Replication. В случае отказа мы вручную запускаем DR-план на второй площадке, он автоматически прекращает попытки реплицировать, затем регистрирует ВМ в vCloud Director, кастомизирует IP-адреса (чтобы не пришлось менять их на ВМ) и запускает ВМ в нужном порядке. В нашем решении менять адресацию не нужно, мы растягиваем сети на оба ЦОДа.
Машины реплицируются постоянно, но не весь ЦОД, а только выбранные — критичные процессы. Реплицируется раз в какое-то время, минимальный интервал — 15 минут (это идеальный случай, когда всё летает и есть выделенный сервер репликации и минимум изменений на ВМ). На практике у вас есть копия на полчаса или час назад. Если что-то пошло не так, то данные, которые попали в интервал, потерялись. 15 минут — это вопрос агента, который собирает новую репликацию. Veeam говорят, что могут меньше 15 минут, но по факту тоже на практике дольше, если не используют фичи СХД. Я не видел на промышленной машине (не на тесте), чтобы было иначе.
Уже давно у NetApp, как и у многих других производителей СХД, есть технология SnapMirror, которая позволяет переложить работу по репликации с гипервизоров на СХД, и VMware Replication умеет этим пользоваться.
Пока сервис репликации пробежит, поезд уходит далеко. Но зато это дёшево.
Почему ещё дёшево — потому что можно использовать любую СХД с любой стороны (от разных производителей, разного класса), не надо выделять заранее большой объём дисков.
Не надо выделять большую дисковую группу, внутри которой нарезаются луны. Просто берётся место на локальной СХД и применяется по факту наличия записи от виртуальной машины. За счёт этого оптимальнее занимается место на СХД, если она используется под другие задачи. А она используется, так как мы не всем клиентам даём такую услугу.
Минус — надо настраивать репликацию на уровне ВМ, то есть контролировать, что всё верно настроено, что это та машина, следить за тем, что репликация проходит, что ошибок нет. Создавать DR-планы для каждого клиента, проводить их испытания.
В первом случае СХД берётся, условно, инфраструктурно, чуть ли не по секторам (точнее, по объектам). А тут одна машина может отвалиться по причине отваливания задачи из-за каких-то софтверных причин, связанных с багом на высоких уровнях, или из-за проблем с доступностью. Это случается чуть чаще, чем если брать именно низкие уровни.
В плюсе — DR хранит несколько точек. Можно откатиться на несколько снепшотов назад.
Снаружи от гостевых ОС нужен дополнительный софт.
Чтобы до Vcloud Director прокинуть все нужные сети, нужна работа нашего администратора. Вообще, вся сетевая связность в этом варианте остаётся на нашем администраторе. Для клиента облака это означает заявку, что тоже занимает время.
Репликация настраивается тоже через заявку. Добавил ВМ — надо отправить заявку, что необходимо её реплицировать. Автоматом она в задачи по репликации не попадёт. Нужно уделять внимание админу.
Разница
В итоге цена может отличаться больше чем в два раза. Репликация будет умножать стоимость дискового пространства на два и больше (две полные копии + история изменений), плюс что-то за сервис и резервацию вычислительных ресурсов. В случае с метрокластером стоимость пространства будет умножаться на два, но само пространство будет стоить значительно дороже, плюс надо жёстко резервировать узлы на удалённой площадке. То есть и вычислительные ресурсы должны умножаться на два, мы их не можем утилизировать под что-то ещё.
В случае с метрокластером мы можем использовать только одинаковые типы дисков, чтобы было полное зеркало. Если на основном ЦОДе часть дисков быстрые, часть медленные на 10 тысяч оборотов в минуту, то нужна идентичная конфигурация. В случае реплики возможны более медленные диски на резервной площадке, а это дешевле за счёт хранения. Но при переключении на резерв он окажется по производительности меньше. То есть если он что-то хранит на SSD в основном кластере, а реплицируется на обычные диски, то хранение будет значительно дешевле ценой замедления инфраструктуры резерва.
Прямо сейчас мы выбираем то, что войдёт в более ранний релиз, поэтому хотим посоветоваться: можете коротко рассказать, как вы организуете свои DR-площадки и что бы от них хотели вообще в целом?
Удалить! Да, я уверен!
Как мы все с вами знаем, простое удаление файлов в Windows совершенно не означает того, что ненужные данные будут действительно уничтожены. По умолчанию файлы просто перемещаются в «Корзину», откуда они могут быть восстановлены парой кликов мышью. Мимо «Корзины» удалять файлы можно с помощью комбинации Shift + Delete. Это уже лучше, но ненамного. Данные все равно физически не стираются, области, в которых они хранятся, только помечаются как свободные для записи. По сути операционная система просто удаляет ссылку на файл из своей базы, считая с этого момента соответствующее место на диске свободным. Более того, поскольку данные хранятся в кластерах, может возникнуть такая ситуация, когда файл не полностью занимает определенный кластер. Например, для его записи понадобилось десять полных кластеров и еще одна половинка, но последний кластер резервируется целиком. Так вот, в этой зарезервированной половинке вполне может сохраняться информация от файла, который был записан в этом кластере ранее. Таким образом данные могут спокойно лежать на диске еще довольно долго до того момента, как поверх них будут записаны новые. То, что операционная система их «не видит», не означает, что они удалены, в чем несложно убедиться, запустив какую-либо из программ для восстановления нечаянно удаленных файлов. Работа с псевдоудаленными данными даже сугубо софтовыми средствами – достаточно перспективный вариант, позволяющий восстанавливать большой процент скрытых файлов.
Для того чтобы быть уверенным в удалении данных, лучше обратиться к одной из специализированных программ. Идеальная политика – постоянное использование программ-шредеров, которые при удалении будут физически уничтожать данные, а также периодическая чистка свободного пространства на носителях. Наилучшие результаты получатся, конечно, если вы будете так работать с самого момента установки накопителя. Однако мы рассмотрим более реалистичный вариант – разовые акции на рабочем диске – и попробуем подобрать подходящий, желательно максимально простой, инструмент.
Программы-чистильщики используют одинаковый принцип: принудительно обнуляют данные или записывают поверх «пустого» пространства информационный мусор. В результате такой перезаписи ранее удаленные данные становятся действительно безвозвратно уничтоженными. После такой обработки распространенные программы восстановления если и найдут что-то, то это будут пустые файлы или случайным образом сгенерированный мусор. Алгоритмы конкретной реализации основного принципа отличаются.
Одно из самых простых в работе решений – программа File Shredder (www.fileshredder.org). Ее можно применять как для надежного удаления файлов, так и для зачистки незанятого пространства. Это маленькая, простая и неприхотливая программка, лишенная дополнительных инструментов вроде планировщика, однако прекрасно справляющаяся со своей основной задачей. При удалении файла File Shredder перезаписывает занимаемое им пространство случайными данными. Программа распространяется по лицензии GNU/GPL и полностью бесплатна.
В софтине доступны несколько алгоритмов удаления данных, отличающиеся количеством проходов и особенностями перезаписи. У этой программы есть плагин для «Проводника» Windows, который позволяет обращаться к ее функциям напрямую из контекстного меню.
Можно встретить отзывы о том, что после работы File Shredder при определенном стечении обстоятельств иногда все-таки удается восстановить значимые фрагменты информации. Один из возможных «самодельных» путей перестраховаться, подходящий для небольших носителей, например флэшек, заключается в удалении файлов, последующей записи на носитель любых бесполезных файлов до его полного заполнения, а потом отправки этих файлов под веник шредера.
Программа File Eraser & Drive Wiper (www.hardwipe.com) предлагает как стандартный инсталлятор, так и портативную версию, которую достаточно просто распаковать, правда, в этом случае не будет работать интеграция опций софтины в системные меню. Русский перевод интерфейса устанавливается отдельным пакетом, также доступным на сайте разработчика. Главный недостаток этой бесплатной программы в том, что она поддерживается рекламой, демонстрируемой в приложении.
Приложение достаточно простое, с быстрым доступом к основным опциям. Поддерживается прямое удаление файлов, очистка дисков целиком, а также очистка «Корзины» и незанятого дискового пространства. В контекстном меню Windows доступны все эти возможности, в том числе зачистка логических дисков. Кроме того, туда вынесены настройки программы, с помощью которых можно определить опции удаления. Предусмотрены некоторые инструменты автоматизации процесса. Ресурсоемкие и длительные задания выполняются в фоновом режиме, возможно автоматическое выключение компьютера по их завершении. После окончания очистки программа выдает отчет о содержании проведенной работы.
Не могу не отметить заявленную разработчиками поддержку ГОСТ Р 50739-95 «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Общие технические требования». Согласно этому стандарту, удаление данных предусматривает обнуление памяти и последующую запись на носитель случайно сгенерированных данных – другими словами, очистку в два прохода. Есть здесь и профиль Gutmann, предусматривающий аж 35 проходов для каждого сектора.
Немного сложнее устроена программа Eraser (eraser.heidi.ie). С ее помощью можно не только проводить единовременные акции, но и планировать защищенную очистку пространства. Eraser умеет работать с файлами и папками, а также самостоятельно чистить системную «Корзину», зачищать «пустое» пространство и другие темные уголки файловой системы Windows. Программа способна взаимодействовать не только с отдельными IDE- или SCSI-дисками, но и с RAID-массивами. Поддерживаются файловые системы FAT и NTFS. В опциях можно четко задать очистку «половинчатых» кластеров (Erase Cluster Tips).
Если какой-либо файл оказался недоступным, например, к нему в момент попытки обращалась другая программа, что привело к его блокировке, Eraser сбросит соответствующее сообщение в довольно информативный отчет. Кстати говоря, эта софтина вообще любит сохранять много ненужной, в общем-то, информации о своих действиях, так что периодически есть смысл чистить ее логи и файл Task List.ersx. Такая процедура лечит и некоторую «задумчивость» программы при запуске.
Как и другие программы-шредеры, Eraser умеет работать с различными алгоритмами удаления данных. Коллекция содержит 13 методов, в том числе ГОСТ Р 50739-95. Жемчужина коллекции – все тот же Gutmann с 35-кратным резервированием. Кроме того, программа умеет записывать в очищаемое пространство фрагменты заданных пользователем файлов. В результате можно не только уничтожить данные, но и попытаться скрыть следы такой чистки: для программ восстановления данных обработанный диск будет выглядеть обычным «цивилом».
Пару слов о выборе алгоритма удаления. Как правило, настройке поддается количество циклов перезаписи, которых может быть до нескольких десятков. Здесь нужно помнить про баланс между количеством проходов и затратой системных ресурсов, поскольку дополнительные проходы существенно замедляют процесс. На емких винчестерах он в результате может затянуться на долгие-долгие часы. Вообще-то, такие избыточные алгоритмы несут не так много практической смысловой нагрузки. Даже однократный проход по простейшему сценарию по большому счету переносит проблему нечаянной утечки данных в отвлеченно-теоретическую сферу. Пространство, на котором работают шредеры, от изменения алгоритма не меняется, так что если программа не смогла дотянуться до файла при активированном алгоритме однократного стирания, она это не сделает и при тридцатипятикратном. Ничего, кроме резкого увеличения времени, необходимого для процедуры очистки, это не принесет. Так что, по моему личному мнению, если уж есть позыв впасть в паранойю, стоит выбирать для этого более приятные формы.
Под занавес – самый надежный рецепт. Ситуации бывают разные. Например, диск потихоньку выходит из строя, на нем большое количество битых секторов, и путь ему только на помойку. В таком случае хочется просто быть уверенным, что никакие персональные данные даже гипотетически не попадут в руки кому-либо еще. Самый брутальный способ – физическое уничтожение устройства. Так что после софтовой чистки включаем режим «умелые руки»: кладем перед собой носитель, берем молоток или наждачку — и, полагаю, внутренний берсеркер подскажет вам, что делать дальше. Для пущей надежности можно поставить рядом парочку кактусов и обратиться к духам вуду.
Сохранить данные и веру в человечество: большая миграция кластера ElasticSearch
В этом материале я продолжаю делиться полевым опытом работы с системой сбора логов на базе Heka и ElasticSearch.
На этот раз рассказ пойдет про миграцию данных между двумя кластерами ElasticSearch 2.2 и 5.2.2, которая стоила немалых нервов лично мне. Как-никак, предстояло перевезти 24 миллиарда записей, не сломав уже работающую систему.
Прошлая статья закончилась на том, что система работает, логи поступают и складываются в кластер ElasticSearch, доступен их просмотр в реальном времени через Kibana. Но кластер изначально был собран со значительным запасом по памяти как раз на вырост.
Если обратиться к официальной документации ElasticSearch (далее просто ES), то в первую очередь вы увидите строгое предупреждение «Don’t cross 32 gb». Превышение грозит проседанием производительности вплоть до моментов полной остановки, пока garbage collector выполняет пересборку в духе «stop the world». Рекомендация производителя по памяти на сервере: 32 ГБ под heap (xms/xmx) и еще 32 ГБ свободного места под кэш. Итого 64 ГБ физической памяти на одну дата-ноду.
Но что делать, если памяти больше? Официальный ответ все в той же документации – ставить несколько экземпляров ES на один хост. Но мне такой подход показался не совсем правильным, так как штатных средств для этого не предусмотрено. Дублировать init-скрипты – это прошлый век, поэтому более интересной выглядела виртуализация кластера с размещением нод в LXD-контейнерах.
LXD (Linux Container Daemon) – так называемый «контейнерный легковизор». В отличии от «тяжелых» гипервизоров не содержит эмуляции аппаратуры, что позволяет сократить накладные расходы на виртуализацию. К тому же имеет продвинутый REST API, гибкую настройку используемых ресурсов, возможности переноса контейнеров между хостами и другие возможности, более характерные для классических систем виртуализации.
Вот такая вырисовывалась структура будущего кластера.
К началу работ под рукой было следующее железо:
Четыре работающих дата-ноды ES в составе старого кластера: Intel Xeon 2x E5-2640 v3; 512 ГБ ОЗУ, 3×16 ТБ RAID-10.
По задумке, на каждом физическом сервере будет две дата-ноды ES, мастер-нода и клиентская нода. Кроме того, на сервере разместится контейнер-приёмник логов с установленными HAProxy и пулом Heka для обслуживания дата-нод этого физического сервера.
Подготовка нового кластера
В первую очередь нужно освободить одну из дата-нод – этот сервер сразу уходит в новый кластер. Нагрузка на оставшиеся три возрастет на 30%, но они справятся, что подтверждает статистика загрузки за последний месяц. Тем более это ненадолго. Далее привожу свою последовательность действий для штатного вывода дата-ноды из кластера.
Снимем с четвертой дата-ноды нагрузку, запретив размещение на ней новых индексов:
Теперь выключаем автоматическую ребалансировку кластера на время миграции, чтобы не создавать лишней нагрузки на оставшиеся дата-ноды:
Собираем список индексов с освобождаемой дата-ноды, делим его на три равные части и запускаем перемещение шардов на оставшиеся дата-ноды следующим образом (по каждому индексу и шарду):
Когда перенос завершится, выключаем освободившуюся ноду и не забываем вернуть ребалансировку обратно:
Если позволяют сеть и нагрузка на кластер, то для ускорения процесса можно увеличить очередь одновременно перемещаемых шардов (по умолчанию это количество равно двум)
Пока старый кластер постепенно приходит в себя, собираем на трёх имеющихся серверах новый на базе ElasticSearch 5.2.2, с отдельными LXD-контейнерами под каждую ноду. Дело это простое и хорошо описанное в документации, поэтому опущу подробности. Если что – спрашивайте в комментариях, расскажу детально.
В ходе настройки нового кластера я распределил память следующим образом:
Клиентские ноды: 8 ГБ
Такое распределение родилось после осмысления документации, просмотра статистики работы старого кластера и применения здравого смысла.
Синхронизируем кластеры
Итак, у нас есть два кластера:
Старый – три дата-ноды, каждая на железном сервере.
Первое, что делаем, – включаем зеркалирование трафика в оба кластера. На приемных пулах Heka (за подробным описанием отсылаю к предыдущей статье цикла) добавляем ещё одну секцию Output для каждого обрабатываемого сервиса:
После этого трафик пойдет параллельно в оба кластера. Учитывая, что мы храним индексы с оперативными логами компонент не более 21 дня, на этом можно было бы и остановиться. Через 21 день в кластерах будут одинаковые данные, а старый можно отключить и разобрать. Но долго и скучно столько ждать. Поэтому переходим к последнему и самому интересному этапу – миграции данных между кластерами.
Перенос индексов между кластерами
Так как официальной процедуры миграции данных между кластерами ES на момент выполнения проекта не существует, а изобретать «костыли» не хочется – используем Logstash. В отличии от Heka он умеет не только писать данные в ES, но и читать их оттуда.
Судя по комментариям к прошлой статье, у многих сформировалось мнение, что я почему-то не люблю Logstash. Но ведь каждый инструмент предназначен для своих задач, и для миграции между кластерами именно Logstash подошёл как нельзя лучше.
На время миграции полезно увеличить размер буфера памяти под индексы с 10% по умолчанию до 40%, которые выбраны по среднему количеству свободной памяти на работающих дата-нодах ES. Также нужно выключить обновление индексов на каждой дата-ноде, для чего добавляем в конфигурацию дата-нод следующие параметры:
По-умолчанию индекс обновляется каждую секунду и создает тем самым лишнюю нагрузку. Поэтому, пока в новый кластер никто из пользователей не смотрит, обновление можно отключить. Заодно я создал шаблон по умолчанию для нового кластера, который будет использоваться при формировании новых индексов:
С помощью шаблона выключаем на время миграции репликацию, тем самым снизив нагрузку на дисковую систему.
Для Logstash получилась следующая конфигурация:
В секции input описываем источник получения данных, указываем системе, что данные нужно забирать пачками (bulk) по 5000 записей, и выбираем все записи, отсортированные по timestamp.
В output нужно указать назначение для пересылки полученных данных. Обратите внимание на описания следующих полей, которые можно получить из старых индексов:
document_type – тип (mapping) документа, который лучше указать при переезде, чтобы имена создаваемых mappings в новом кластере совпадали с именами в старом – они используются в сохранённых запросах и дашбордах.
Параметры запуска Logstash:
Ключевыми параметрами, влияющими на скорость миграции, являются размер пачек, которые Logstash будет отправлять в ES, и количество одновременно запускаемых процессов (pipeline.workers) для обработки. Строгих правил, которые определяли бы выбор этих значений, нет – они выбирались экспериментальным путем по следующей методике:
Выбираем небольшой индекс: для тестов использовался индекс с 1 млн многострочных (это важно) записей.
Запускаем миграцию этого индекса с помощью Logstash.
Смотрим на thread_pool на приёмной дата-ноде, обращая внимание на количество «rejected» записей. Рост этого значения однозначно говорит о том, что ES не успевает проиндексировать поступающие данные – тогда количество параллельных процессов Logstash стоит уменьшить.
После того как всё было подготовлено, составлены списки индексов на переезд, написаны конфигурации, а также разосланы предупреждения о предстоящих нагрузках в отделы сетевой инфраструктуры и мониторинга, я запустил процесс.
Чтобы не сидеть и не перезапускать процесс logstash, после завершения миграции очередного индекса я сделал с новым файлом конфигурации следующее:
Список индексов на переезд разделил на три примерно равные части.
В /etc/logstash/conf.d/migrate.conf оставил только статическую часть конфигурации:
Собрал скрипт, который читает имена индексов из файла и вызывает процесс logstash, динамически подставляя имя индекса и адрес ноды для миграции.
Код одного из экземпляров скрипта:
Процесс миграции занял около недели. И честно скажу – спалось мне эту неделю неспокойно.
После переезда
После переноса индексов осталось сделать совсем немного. В одну прекрасную субботнюю ночь старый кластер был выключен и изменены записи в DNS. Поэтому все пришедшие на работу в понедельник увидели новый розово-голубой интерфейс пятой Kibana. Пока сотрудники привыкали к обновленной цветовой гамме и изучали новые возможности, я продолжил работу.
Из старого кластера взял еще один освободившийся сервер и поставил на него два контейнера с дата-нодами ES под кластер новый. Все остальное железо отправилось в резерв.
Итоговая структура получилась точно такой, какой планировалась на первой схеме:
Три клиентские ноды.
Восемь дата-нод (по две на сервер).
Переводим кластер в production режим – возвращаем параметры буферов и интервалы обновления индексов:
Кворум кластера (учитывая три мастер-ноды) выставляем равным двум:
Далее нужно вернуть значения шард, принимая во внимание, что дата-нод у нас уже восемь:
Наконец, выбираем удачный момент (все сотрудники разошлись по домам) и перезапускаем кластер.
Нашардить, но не смешивать
В этом разделе я хочу обратить особое внимание на снижение общей надёжности системы, которое возникает при размещении нескольких дата-нод ES в одном железном сервере, да и вообще при любой виртуализации.
С точки зрения ES кластера – всё хорошо: индекс разбит на шарды по количеству дата-нод, каждый шард имеет реплику, primary и replica шарды хранятся на разных нодах.
Система шардирования и репликации в ES повышают как скорость работы, так и надёжность хранения данных. Но эта система проектировалась с учётом размещения одной ноды ES на одном сервере, когда в случае проблем с оборудованием теряется лишь одна дата-нода ES. В случае с нашим кластером упадут две. Даже с учетом равного разделения индексов между всеми нодами и наличия реплики для каждого шарда, не исключена ситуация когда primary и replica одного и того же шарда оказываются на двух смежных дата-нодах одного физического сервера.
Поэтому разработчики ES предложили инструмент для управления размещением шард в пределах одного кластера – Shard Allocation Awareness (SAA). Этот инструмент позволяет при размещении шард оперировать не дата-нодами, а более глобальными структурами вроде серверов с LXD-контейнерами.
В настройки каждой дата-ноды нужно поместить ES атрибут, описывающий физический сервер, на котором она находится:
Теперь нужно перезагрузить ноды для применения новых атрибутов, и добавить в конфигурацию кластера следующий код:
Причем только в таком порядке, ведь после включения SAA кластер не будет размещать шарды на нодах без указанного атрибута.
Кстати, аналогичный механизм можно использовать для нескольких атрибутов. Например, если кластер расположен в нескольких дата-центрах и вы не хотите туда-сюда перемещать шарды между ними. В этом случае уже знакомые настройки будут выглядеть так:
Казалось бы, все в этом разделе очевидно. Но именно очевидное и вылетает из головы в первую очередь, так что отдельно проверьте – тогда после переезда не будет мучительно больно.
Следующая статья цикла будет посвящена двум моим самым любимым темам – мониторингу и тюнингу уже построенной системы. Обязательно пишите в комментариях, если что-то из уже написанного или запланированного особенно интересно и вызывает вопросы.