Как стать автором
Обновить

Как пережить масштабирование и синхронизировать-таки всё между дата-центрами

Блог компании uKit GroupСерверная оптимизацияСерверное администрированиеВосстановление данныхХранение данных
Всего голосов 32: ↑32 и ↓0 +32
Просмотры9.4K
Комментарии 23

Комментарии 23

Какое количество файлов у вас требовалось синхронизировать?
Сейчас там ~50млн. инод и ~6Тб данных.
Хотел вам предложить syncthing, но да, для такого количества слишком много ему нужно будет памяти.
Интересно, посмотрим и на него тоже, спасибо)
26 USD стоит 24 бутылки по 0,5 л.
Спасибо, пасхалка «кто сходит и прочакает проверит» unlocked. Там еще тарификация весьма забавная у него с этими 26-ю баксами и числом бутылок.

P.S. Вспомнилось:
Когда Чак Норрис входит в воду, он не становится от нее мокрый — вода становится чаковой.
я в третьем ряду с низу, третий с права)
Уважаемый товарищ, чьи мыcли мы так и не поняли.

От этого уважаемого товарища в тот же день вышла другая статья, которая кстати, вам очень подходит.
Краткая её суть такая: если у вас маленькие файлы и вы всегда можете читать/писать их целиком, вы можете использовать key-value хранилище.
Когда у вас куча мелких файлов, важной проблемой становятся накладные расходы на поиск файла в ФС.
key-value хранилища эту проблему решают.
Рекомендую вам посмотреть в эту сторону.

Мы смотрели, и написали об этом в той части где описаны проблемы выбора между S3-Like хранилищем и чем-то «своим». Т.е. там подразумевается не только Amazon S3, но и все похожие пути решения, вплоть до Mongodb GridFS.

Боюсь, что здесь в одну кучу смешиваются два вида хранилищ.
S3, Swift и прочие — это объектные хранилища.
А GridFS в MongoDB, как написано в доке — это вообще хранилище для больших файлов ("large files").
Они, конечно, размывают понятие "путь к файлу", но файл у них остается файлом.


Даниил же рассказывает про кластерную NoSQL СУБД.
Т.е., если очень упростить, они хранят файлы, как строки в хранилище типа redis.
Такой трюк можно сделать только с маленькими файлами и там он оправдан.
Поэтому я, как прочитал вашу статью, сразу вспомнил про статью от него.
Он упоминает Aerospike и судя по тестам, вашу задачу она решает быстро и надежно.

Или даже Redis — у nginx есть модуль для работы с memcached-протоколом, можно прямо URI трансформировать в ключи и отстреливать файлы. Заодно бы шардинг получился и репликация.

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

А для mc — написать vfs на питоне занимает 100 строчек. И будет редис на панелях с папками.

Сам redis использовать в таком месте не получится — он все хранит в оперативке и синхронизируется с диском. 6 ТБ данных туда засунуть проблематично. А ещё проблематичней будет эти данные сохранять на диск. Здесь нужен подход традиционных СУБД — хранить данные на диске и по максимуму использовать оперативку под кеширование.

Отвечу здесь и на этот, и на предыдущий ваш комментарий. И, возможно, еще на чьи-то.
Во-первых, спасибо за замечание, видимо я не совсем понятно выразился. Мысль была в том, что у нас было, грубо говоря, 2 пути: засунуть файлы в какую-нибудь базу и не засунуть. Понятно, что баз много, хороших и разных. Но нам бы тогда, повторюсь, пришлось переписывать весь код работы с файлами и менять подход к работе с ними, в том числе к их отдаче. Также напомню, что у нас разные ДЦ, т.е. непредсказуемая latency и весьма условный 1Gbps между нодами. Взвесив все «за» и «против» мы выбрали вариант без баз. Безусловно, у обоих вариантов есть недостатки и преимущества.
> написать vfs на питоне занимает 100 строчек
Вы предлагаете использовать FUSE? Посмотрите, автор привел объемы данных. Представляете накладные расходы на путешествия user — kernel — user на каждый чих?
FUSE-решения хороши, когда нужно сделать удобно, но о скорости там речи не идёт вообще. GlusterFS это наглядно показал.
Да какой fuse, у mc есть система плагинов, чтобы входить во всякие там архивы и т.д. на панели. Например, вот для AWS S3: https://github.com/MidnightCommander/mc/blob/master/src/vfs/extfs/helpers/s3%2B.in (я немного контрибутил туда).

Это не для работы в продакшене, это для отладки. (В статье упоминалось, что один из недостатков иметь данные в key-value storage по сравнению с файлами, — это невозможность ходить по структуре файлов в mc; в принципе, сам по себе аргумент достаточно сильный ИМХО — отладка очень важна.)
Если я правильно понял автора, то им всё же нужно в итоге иметь файловое представление. Поэтому mc подойдет только для отладки и всё равно по сути своей будет аналогом FUSE, а значит — медленно.
А не смотрели в сторону zfs -> snapshoot, передавать и применять дифф снапшота? Говорят, должно работать. Хотя куст файлов у вас серьезный, да. Возможно, стоит просто уходить от обычных ФС в сторону чего-нибудь виртуального.
Честно говоря, не смотрели. А ZFS под Linux уже production-ready?
Да, более чем. У нас несколько БД так крутятся — бэкап удобно снимать — остановил, снапшот сделал, запустил, и потихонечку снапшот вытягиваешь, а БД продолжает работать.
Но если есть недоверие к пингвину, можете посмотреть на FreeBSD. Есть мнение, что там оно роднее. Хотя, есть и другие мнения =)
Мы, кстати, тоже так бэкапим БД, только снапшотим средствами LVM. Но я не совсем понял в чем идея. Делать снапшоты одновременно на обоих серверах, как-то diff-ать их по сети и применять изменения на «слэйв-сервере»?
Читать в сторону zfs send -i
docs.oracle.com/cd/E19253-01/820-0836/gbchx/
Честно — сами такое ещё не пробовали, но zfs крута и вполне может быть. Если теоретизировать, то механизм CoW должен позволять очень быстро получить набор изменений относительно снапшота. Тогда, если у вас изменения только на условном мастере и их относительно мало, то дифф будет небольшой, быстрый и накатить его на RO слейв не займет времени. Ну и плюс все остальные плюшки ZFS (про минусы тоже надо помнить!).
Как я понял Максим это программист. А как известно если ты молоток то вокруг только гвозди. Нельзя программистам давать такие задачи. Все программисты в любых программных продуктах видят изъяны и готовы порвать майку на груди и написать свою еще лучше. Такие задачи должный решать архитекторы или интеграторы. Вы говорите что у вас не крупный проект но при этом берете решение VK (ну они то точно мелкий стартап).
Как раз небольшым проектам нужно брать готовые решение и для этого есть пару аргументов.
1. Готовое решение имеет комьюнити и там всегда идет работа над уличением продукта.
2. Только используя готовое решение долгое время можно понять что действительно вам нужно. Чтоб потом когда вы станете крупным проектом со штатом в сотни программистов написать что-то свое пользуясь опытом других. И этим проектом будет занимать целый отдел а не один программист.
3. Как часто бывает у подобных самописных решений очень сложная кодовая база, очень сложная инфраструктура и точно у этого всего нет документации. Долгих лет Максиму. Но случись что с ним вы будете смотреть на страдание того кто это возметься поддерживать. А еще вы точно от него услышать что это все нужно переписать так как это чужой программный продукт и там кучу изъянов. И новая итерация самописного $#@ ПО
ИМХО. Не пишете свои велосипеды там где задачи стары как мир используйте готовое решение. А это задача именованием такая и решена уже сотнями способов под все случаи жизни.
Какие именно сотни способов решают эту задачу в нашем случае? Предложите наиболее подходящий с вашей точки зрения, нам очень интересно ваше мнение. Заранее спасибо!
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.