Комментарии
10
В разделе Отказоустойчивость вы описываете:
А почему не RAID6?
Насчет дедупликации, довольно сложный алгоритм со слабым звеном — индекс.
Если индекс «слетит», то все ваши данные потеряют связи и станут orphans.
Потеряются данные и восстановить, судя по алгоритму, никак.
Или я ошибаюсь?
Если сегмент существует в единственном экземпляре, то что произойдёт в случае его потери? Если диск, на котором хранится популярный сегмент выйдет из строя, будет ли это означать невозможность чтения всех ссылающихся на него версий? ...
А почему не RAID6?
Насчет дедупликации, довольно сложный алгоритм со слабым звеном — индекс.
Если индекс «слетит», то все ваши данные потеряют связи и станут orphans.
Потеряются данные и восстановить, судя по алгоритму, никак.
Или я ошибаюсь?
Отказоустойчивость хранения данных в системе должна обеспечиваться на разных уровнях. Система должна переживать потерю диска, контроллера, сервера, стойки, машинного зала, дата-центра (в зависимости от требований заказчика). Действительно, как и в RAID6, в нашем алгоритме отказоустойчивого хранения данных используются коды коррекции ошибок. Однако RAID6 решает проблему лишь на уровне потери диска в массиве, но не решает её на других уровнях. Кроме того, RAID6 имеет ограничения по масштабированию. Чем больше диски, тем дольше rebuild time и тем выше шансы, что disk scrubbing (фоновая процедура исправления ошибок) не успеет обнаружить возможные ошибки дисков. Наш подход более гибкий и потенциально позволяет обеспечивать гарантии отказоустойчивости данных и на других уровнях.
Что касается метаданных (индексов), то их отказоустойчивое хранение реализовано с помощью других алгоритмов. Мы обязательно вернёмся к этим темам в статьях, посвящённых горизонтальному масштабированию Dispersed Object Store.
Что касается метаданных (индексов), то их отказоустойчивое хранение реализовано с помощью других алгоритмов. Мы обязательно вернёмся к этим темам в статьях, посвящённых горизонтальному масштабированию Dispersed Object Store.
А письма по 500К — это какой-то реальный кейс из вашей практики? Это же очень-очень много текста
Для генерации тестового сета мы опирались на статистику, которую нам предоставили некоторые из заказчиков. В корпоративной среде электронные письма действительно могут быть очень большими.
Цитирования с перечислением адресатов превращают даже простые сообщения в письма огромных размеров, особенно когда к переписке подключают новых людей.
Ещё один частый случай — это письма, формируемые в результате коллаборативной работы над документами. Зачастую они содержат как оргинал текста, так и его редакцию. Например, письма с diff'ами, рассылаемые Confluence при редактировании крупных документов, легко могут достигать нескольких сотен килобайт форматированного текста.
Цитирования с перечислением адресатов превращают даже простые сообщения в письма огромных размеров, особенно когда к переписке подключают новых людей.
Ещё один частый случай — это письма, формируемые в результате коллаборативной работы над документами. Зачастую они содержат как оргинал текста, так и его редакцию. Например, письма с diff'ами, рассылаемые Confluence при редактировании крупных документов, легко могут достигать нескольких сотен килобайт форматированного текста.
даже потеря бизнеса компанией DataMouse
Из любопытства решил загуглить, не нашёл ни единой ссылки, кроме ссылок на данную статью (уже проиндексирована поисковиками).
Спасибо, это опечатка. Имелась в виду компания CloudMouse. Поправили.
В статье опечатка, речь идет про историю CloudMouse
Если поискать на Habr
Да, беглый поиск не дал результатов разбора, что именно у них поломалось и почему.
И рядом же нашлось сообщение о проблемах в Selectel с mdadm в 2012 году, тоже хотелось найти информацию о том, докопались ли до причины ошибки в итоге. Но сходу найти не удалось, только расследование проблемы.
Довольно неплохо разобран типовой отказ Ceph тут
Основная проблема Ceph – плохая прогнозируемость эксплуатации. Строить коммерческие системы на нем можно, точно понимая что делать во время отказа и имея в запасе инженерную команду, способную эти проблемы чинить на уровне кода.
Это совсем другая модель и компаниям, которые не занимаются разработкой системного ПО такой подход не годится.
Спасибо за ссылку.
Я думал, что за 7 прошедших лет должны были быть значительные улучшения. Столько больших компаний над Ceph работают...
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Почтовая система Mailion: как нам удалось создать эффективное объектное хранилище для электронной почты