Если нет, то он гонит трафик на Amazon, где продает бутылочки воды за $26, а мы расскажем о сайтах в нашем SaaS-конструкторе

Ни одна площадка не может гарантировать бесперебойную работу в течение, например, года — это данность по целому ряду причин. Значит, надо иметь “план Б” — обеспечить отказоустойчивость на уровне дата-центра и создать резервную площадку, которая чуть что подхватит трафик. Синхронизируют сервера все — и Яндекс, и Гугл, и герои под катом.

Когда мы начинали делать новый конструктор сайтов, в команде было всего 10 человек, вместо такого офиса рабочим местом была квартира (ненадолго, но есть что вспомнить), а текущие 700 000 пользователей, ~50млн инод и ~6Тб данных маячили на далеком горизонте. Это дало нам возможность больше года экспериментировать с синхронизацией серверов — а параллельно выпытывать у коллег из других проектов, как и что устроено у них.

После энного эксперимента и посещения энного сикретне мероприятия, наш программист Максим пришел и сказал: “Кажется, не мы одни такие полоумные”. Короче, мы сделали полностью свою систему синхронизации. И сейчас расскажем, почему.

Пролог: uKit глазами сисадмина

Одной из главных сущностей в нашей системе является “сайт” — это документ в базе, который содержит ссылки на составляющие его “виджеты”, которые как-то расставлены и чем-то наполнены со стороны пользователя. Расставив и заполнив виджеты на свой вкус, пользователь решает, что пора нажать кнопку “опубликовать” — и его сайт должен попасть, так сказать, в продакшн.


Поскольку в качестве основной БД для проекта мы выбрали MongoDB, то особенно не переживали насчет отказоустойчивости: ведь есть асинхронная репликация “из коробки”, с этим всё хорошо.

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

Вот какой путь прошли мы в поисках:

Изобретаем свой “хайлоад”

Какие проблемы могут возникнуть с голым Rsync’ом

Добавим асинхронности? А, нет, не добавим

На распутье: Amazon или свой Лунапарк?

Поворотный момент: или как делают старшие товарищи

“Расческа Вершанского”: как решить проблему параллельности при асинхронности

Не думай о наносекундах свысока: что учесть при тестировании самописной системы

Хэппи-энд: героическое спасение рядовых серверов

Изобретаем свой “хайлоад”

Первой идеей было копировать текущее состояние сайта в отдельную коллекцию. В таком виде задачу и отдали программисту: но повозившись над ней, он предложил просто взять и сдампить всё в файлики, да и положить на диск. У Максима вообще склонность бережно относиться к ресурсам системы.

Поразмыслив, мы постепенно начали проникаться этой идеей: с точки зрения “хайлоада” ничего лучше и надежнее придумать-то, наверное, нельзя: отдать файл с диска Nginx-ом, с его всепобеждающим сендфайлом и тред-пулами. База, какой бы хорошей она ни была, всё равно рано или поздно начинает требовать шардирования, построения новых индексов и прочих регламентных работ. А мы делаем высоконагруженный сервис, мы обязаны думать о таких вещах. В конце концов, так даже проще.

Какие проблемы могут возникнуть с голым Rsync’ом

Итак, у нас есть статические файлы, в основном HTML и картинки в разных форматах. Как синхронизировать не так уж много файлов между двумя серверами? Rsync-ом.

Пока мы были достаточно маленькими, то просто повесили на cron синхронизацию всей директории с сайтами каждую минуту (с lock-файлом). Скрипт отрабатывал за секунду, мы несколько раз переключались между серверами и горя не знали.


Задача маркетологов — сделать так, чтобы сайтов в системе стало побольше. И надо сказать, с задачей они справляются.

Мы начали замечать, что lock-файл в часы пик начинает висеть по 10 и более минут — иерархия директорий подросла, и Rsync уже не успевал обойти всю её быстро. Rsync же сначала обойдет все директории на источнике, построит дерево, получит аналогичное дерево с приемника, сравнит… И только после этого начнет что-то отправлять — что тоже занимает время. Как результат, статика на втором сервере отстает — причем расхождение идет не от какого-то определенного момента времени, что добавляет проблем.

Добавим асинхронности? А, нет, не добавим

Так мы пришли к идее “распределенных файловых систем” — их в мире существует предостаточно: LeoFS, LustreFS, GlusterFS, XtreemFS, WhateverFS. Но на тот момент (может, что и поменялось) все либо были синхронными, либо асинхронный режим у них фактически не работал. Или работал слишком плохо.

Порывшись на Хабре, мы обнаружили проект Lsyncd — работает он посредством Inotify-вотчеров, навешиваемых на каждую директорию, и того-же самого Rsync-а, который срабатывает при событиях создания/изменения/удаления файлов. Мы решили попробовать: на наш миллион директорий оно навешивало свои вотчеры около часа, но в итоге заработало и начало что-то синхронизирновать. Но оказалось, что у Lsyncd проблемы с retry-ями и запоминанием длинного списка изменений:



Да и длительные обрывы связи между серверами Lsyncd переживает плохо.

На распутье: Amazon или свой Лунапарк?

Поиски “грааля” привели нас на любопытное распутье из двух вариантов:

Использовать S3-Like хранилище — например, Amazon S3 или один из множества аналогов. Как вариант, развернуть у себя. Такой подход, с одной стороны, позволит перестать думать о том, где и как хранятся наши файлы и начать жить, а с другой — сулит много новых заморочек.

Во-первых, нам придется переписать весь код работы с файлами, да еще и порефакторить места, которые опираются на то, что файл записывается на диск почти мгновенно и сразу же доступен. Во-вторых, мы потеряем возможность ходить по файлам Midnight Commander-ом, что периодически бывает нужно при отладке.

В-третьих, если файлы при такой схеме лежат у чужих дядек, они могут устроить нам любую пакость — например, внезапно поднять цену в два раза или уронить свой сервис, ошибившись окошком. Да, файлы могут лежать у нас в каком-нибудь Swift/Elliptics/Riak — но это разумно, когда данных в десятки раз больше чем у нас — если ты Яндекс, например. Там же сразу ставится на 5 серверов — три с данными и два управляющих, это минимум.

В общем, сложнее, чем нужно для нашей задачи.

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

Недостаток всего один — это надо делать самим, и успеть до того, как у нас закончится место. Моментом X должен был стать канун Нового 2017-го года.

Поворотный момент: или как делают старшие товарищи

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


Уважаемый товарищ, чьи мыcли мы так и не поняли.

Поворотным моментом, пожалуй, стала встреча с ребятами из VK — в кулуарах какой-то конференции мы поинтересовались у них, чем они синхронизируют файлы. Они сказали, что синхронизируют сами, так как ничего хорошего готового тоже не нашли.


Позже мы узнали, что и в Badoo фотки синхронизируются подобным образом.

В общем, Максим засел за написание системы, а я тем временем доставал дисковое пространство из загашников LVM-а и подчищал тяжелые логи.

“Расческа Вершанского”: как решить проблему параллельности при асинхронности

За основу системы мы взяли Rabbitmq (он уже использовался в проекте) и npm-модуль fs — через него проходило большинство операций с файлами. Идея была такой — переопределив модуль fs, мы заставим его записывать все выполняемые действия в очередь и только после этого считать их завершенными (дёргать callback). Рядом с очередью запускается демон, который берет из очереди задание и шлёт его по http в другой демон, который работает на принимающем сервере. Если это создание файла — шлет post-ом этот файл, если удаление — команду delete и так далее.

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

В момент обсуждения этой дилеммы на кухне у доски как-бы-случайно оказался Витя, который всегда как-бы-случайно оказывается рядом, если происходит какое-нибудь интересное обсуждение. Витя начал рисовать вертикальные линии, символизирующие действия CRUD, — линии шли параллельно друг другу и назывались a, b, c, d…


С гитарой — это Витя. Довертеть его идею “расчески” также помогал Паша, который занимается в компании такими вот интересными вещами.

Бинго! Наши файлы хранятся по старой-доброй схеме a/b/c, то есть сайт vasya.ru будет лежать по пути /v/a/s/vasya.ru. Мы решили, что принимающая сторона будет выполнять задания по порядку в пределах одной “верхней” буквы, но за ее пределами — асинхронно. Так получалось и быстро, и надёжно. А поскольку схема Вити на доске напоминала расческу, принцип был назван в честь программиста, оказавшегося в нужное время в нужном месте.

Не думай о наносекундах свысока: что учесть при тестировании самописной системы

Когда уже было что тестировать, мы решили проверять синхронность директорий в двух местах тем же способом, которым мы это делали в далекие времена, — а именно, самим Rsync-ом в режиме dry-run.

С этой опцией на самом деле ничего не происходит, но на экран выводятся действия, которые произошли бы: видно все файлы, которые должны быть скопированы, соответственно, это и есть точки “несинхронности”.



Тут ждала еще одна проблема — ctime файлов наш Node.js выставляет с точностью до миллисекунд (дальше забивает нулями), а Rsync, сравнивая файлы на одинаковость, учитывает еще и наносекунды! И считает файлы разными, когда они на деле одинаковые.

Можно было бы вычислять и сравнивать md5-хэши файлов — но это очень медленно. Поиски готового модуля, способного менять creation time файлов в режиме UltraHD, ни к чему не привели, и пришлось написать свой модуль на C для этих целей. Вот так возвращение к истокам синхронизации вернуло нас к истокам программирования.

Хэппи-энд: героическое спасение двух рядовых серверов

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

В ходе подготовки к переезду написали скрипт “холодной синхронизации”, ласково названный coolSync: чтобы перекачать файлы, которые давно лежат на диске и с ними не производится никаких действий (но какие именно это файлы — мы не знаем). Вариант с обычным рекурсивным Rsync тут не подходил, т.к. эта рекурсия длится вечно, и построенный в итоге список файлов теряет актуальность, не успев достроиться. Наш скрипт генерировал a/b/c пути сам, ходил по ним, обходил папки только “в глубине” и запускал Rsync для каждой отдельной папки на каждой итерации. Всего за какую-то неделю, нам удалось перекачать почти все файлы.


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

Эти проблемы в итоге удалось победить — новый 2017-й год был уже на носу, но как в голливудских блокбастерах, мы справились к часу X. Теперь система работает вот так:

Вместо эпилога

К сожалению, готовых решений для таких проектов как не было, так и нет. Поэтому — стройте свои Лунапарки! И делитесь опытом.