Comments 43
Автор доклада не слышал о существовании таких сервисов, как Amazon S3, Dropbox (точнее, их Magick Pocket), MS Azure storage?
И, кстати, seek — вот вообще не проблема для распределённой POSIX-совместимой файловой системы. Иерархия директорий и особенно атомарность её изменений — намного бОльшая боль.
на ext4 не поддерживается ни сжатие, ни шифрование, там это организовано с помощью блочных устройств, которые поддерживают и то и другоеТак ведь ext4 поддерживает шифрование с середины прошлого года. Эти патчи вошли в ядро Linux 4.1
ЗЫ. Расшифровка «трейдконтроллера с батарейкой» доставила)
Мне самому случалось перепутать source и destination в команде rsing
Это какая неизвестная мне команда, или там должен быть rsync?
И правда, какой-то странный доклад. Зачем так все усложнять? Консистентностью почти всегда можно пожертвовать. Версионирование как защита от ошибки оператора… Ну кто мешает дать оператору такие утилиты, которые исключат возможность ошибки?
Не хватает скорости на запись? Надо увеличить размер кластера. Не хватает скорости на чтение? Надо увеличить коэфф. репликации.
При падении ноды кластер лежит, т.к. восстанавливает данные? А кто мешает не использовать 100% iops для восстановления данных, а реплицировать потихоньку?
Поправьте меня, если я неправ, но n одинаковых серверов с WebDAV + транзакционная база в качестве индекса сможет масштабироваться на любую нагрузку.
P.S. Вконтакте очень даже удаляет старые файлы. Достаточно промотать любой паблик вниз, и на каком-то этапе начнут показываться посты без картинок. Эффективный менеджмент в действии я думаю.
4 хилых десктопных 2х ядерных сервера, в каждом 1-2 БП и 10 — 20 винтов.
Жило это все под фряхой разных релизов, все винты хранилища были зашифрованы, собранны в несколько массивов(на каждый сервер, так как собиралось это не за 1 раз) и на них кроме самих данных хранились данные «клеток»(jail) со своими IP, MAK и DC клиентами.
Все DC клиенты по часам коннектились к общественному DC серверу, половина день и вечер, вторая половина вечер и ночь, свежая и актуальная инфа тупо клонировалась на 2 DC клиентах работающих в разное время.
В 7 фряхе появилась ZFS с кучей плюшек, вроде раскиданного по серверам дискового пространства, снапшетов и т.д.
Порядка 7 лет назад я отошел от администрирования сети и серверов, неужели за эти годы так и не допилили ZFS и нет альтернатив?
Почему нельзя просто сложить все файлы в базу? С моей точки зрения, именно так и надо поступить, потому что если у нас лежат файлы в базе, у нас есть большой пакет хороших средств работы с такими вещами.
А разве данные базы данных не в файлах хранятся?
«Tablespaces on raw partitions» кажется
а так вообще: файлы в таблицах, которые в файлах…
Понятно, что БД в файлах хранит свою информацию) Но ведь доступ к файлу напрямую из ФС — это самый короткий вариант. А доступ к файлу через какую-то БД, которая пойдёт и ковырнёт какой-то огромный массив данных и выплюнет оттуда нужные тебе пару мегабайт — это другое. Да и веб-сервер, к примеру, обычно сам не умеет работать с БД как с файловой системой. Придётся добавить вторую прослойку: какой-нибудь cgi-процесс на каком-нибудь пыхе, который будет обращаться сначала к БД, потом возвращать контент веб-серверу… который, в свою очередь, этот контент уже отдаст клиенту.
Зачем BLOB-хранилищу файловая система, разве оно не должно работать с блочным устройством напрямую?
CAP-теорема – это всего-навсего теорема, ее никто не доказал, но по факту это действительно так.
Если бы её никто не доказал, она не была бы теоремой. Доказали её Сет Гильберт и Нэнси Линч.
А что RAID с зеркалом уже отменили? Вылетел диск. Заменили. Он в фоне дублируется потихоньку, а система продолжает работать. Даже RAID5 и RAID6 вроде не требуют остановки системы для восстановления после сбоя.
> Почему нельзя просто сложить все файлы в базу? С моей точки зрения, именно так и надо поступить, потому что если у нас лежат файлы в базе, у нас есть большой пакет хороших средств работы с такими вещами.
Любая ФС является базой данных.
Любая БД, в которой сохраняют файлы, становится ФС.
автор статьи посчитал время восстановления рейда по максимуму скорости, когда на нем ничего не происходит, в реальности умножайте эти сроки на 10-100, особенно если все высоконагружено.
и да, зеркалирование — дорогое удовольствие, но да в подавляющем большинстве случаев оно спасает
p.s. добавлю к статье очень полезную мысль, делитесь и размножайтесь — не создавайте один большой блок из 100500 дисков, если у вас 30 дисков, сделайте 5 независимых рейдов, по 6 в каждом,… в результате смерть одного диска заставит шевелистья всего 5 оставшихся дисков, вместо всех.
ZFS IMHO иначе RAID не знает где там файлы и 16 часов будет реплицировать все.
Binary Artifact Repository? Не, не слышал.
Binary Artifact Repository? Не, не слышал.
Берем какую-нибудь кластерную файловую систему. Мы попробовали несколько: CEPH/Lustre/LeoFS.
Интересно, а GlusterFS не пробовали? Может она бы подошла.
Т.е. ваше хранилище не должно по первому чиху превращаться в тыкву, которая занята только сохранением спрятанных внутри данных. Если уж данные потерялись, бог с ними, они потерялись, главное, чтобы шоу продолжалось.
Извините, но такое «отдавалище» никому не нужно. Никому не хочется, чтобы конкретно его данные превратились в эту тыкву вообще, а не перестали быть доступными пусть даже несколько дней. Сколько проработает сервис без отказоустойчивости?
если речь идет о публичном сервисе, то выбирая между очень серьезными затратами на отказоустойчивость и шансом того, что 0.01% пользователей потеряет часть своих фоток с котиками...
Называть несущественной проблему потери личных фотографий — ханжество.
Сервис либо должен гарантировать сохранность, либо твёрдо и ясно писать при регистрации, что они ничего не обещают. И что выбор пользователя — заплатить 2000 рублей в год за терабайт облака, или заплатить один раз 15000-25000 за домашний NAS с зеркалом.
Пожалуйста, найдите какие-нибудь другие аргументы, без переходов на личности.
И нет, не должен, и тем более не гарантирует. Просто подумайте, какие усилия надо приложить, чтобы обеспечить 100% сохранность, скажем, одной страницы текста? Чтобы она не сгорела в пожаре, не содержала дефектов при изготовлении копии, не пропала из-за человеческого фактора? А электронные данные более хрупки.
Так что на практике всё упирается в экономическую целесообразность — в стоимость защитных мер, в доходы, в риски потери доходов в случае потери данных.
Электронные данные менее хрупки, потому что позволяют размножить себя без ущерба для оригинала.
Экономическая целесообразность имеет под собой моральную диллему. Готовы ли вы ради спасения тысячи людей убить одного ребенка? Так и тут.
Бинарные (файловые) хранилища, страшная сказка с мрачным концом