Comments 10
В разделе Отказоустойчивость вы описываете:
А почему не RAID6?
Насчет дедупликации, довольно сложный алгоритм со слабым звеном — индекс.
Если индекс «слетит», то все ваши данные потеряют связи и станут orphans.
Потеряются данные и восстановить, судя по алгоритму, никак.
Или я ошибаюсь?
Если сегмент существует в единственном экземпляре, то что произойдёт в случае его потери? Если диск, на котором хранится популярный сегмент выйдет из строя, будет ли это означать невозможность чтения всех ссылающихся на него версий? ...
А почему не RAID6?
Насчет дедупликации, довольно сложный алгоритм со слабым звеном — индекс.
Если индекс «слетит», то все ваши данные потеряют связи и станут orphans.
Потеряются данные и восстановить, судя по алгоритму, никак.
Или я ошибаюсь?
Отказоустойчивость хранения данных в системе должна обеспечиваться на разных уровнях. Система должна переживать потерю диска, контроллера, сервера, стойки, машинного зала, дата-центра (в зависимости от требований заказчика). Действительно, как и в RAID6, в нашем алгоритме отказоустойчивого хранения данных используются коды коррекции ошибок. Однако RAID6 решает проблему лишь на уровне потери диска в массиве, но не решает её на других уровнях. Кроме того, RAID6 имеет ограничения по масштабированию. Чем больше диски, тем дольше rebuild time и тем выше шансы, что disk scrubbing (фоновая процедура исправления ошибок) не успеет обнаружить возможные ошибки дисков. Наш подход более гибкий и потенциально позволяет обеспечивать гарантии отказоустойчивости данных и на других уровнях.
Что касается метаданных (индексов), то их отказоустойчивое хранение реализовано с помощью других алгоритмов. Мы обязательно вернёмся к этим темам в статьях, посвящённых горизонтальному масштабированию Dispersed Object Store.
Что касается метаданных (индексов), то их отказоустойчивое хранение реализовано с помощью других алгоритмов. Мы обязательно вернёмся к этим темам в статьях, посвящённых горизонтальному масштабированию Dispersed Object Store.
А письма по 500К — это какой-то реальный кейс из вашей практики? Это же очень-очень много текста
Для генерации тестового сета мы опирались на статистику, которую нам предоставили некоторые из заказчиков. В корпоративной среде электронные письма действительно могут быть очень большими.
Цитирования с перечислением адресатов превращают даже простые сообщения в письма огромных размеров, особенно когда к переписке подключают новых людей.
Ещё один частый случай — это письма, формируемые в результате коллаборативной работы над документами. Зачастую они содержат как оргинал текста, так и его редакцию. Например, письма с diff'ами, рассылаемые Confluence при редактировании крупных документов, легко могут достигать нескольких сотен килобайт форматированного текста.
Цитирования с перечислением адресатов превращают даже простые сообщения в письма огромных размеров, особенно когда к переписке подключают новых людей.
Ещё один частый случай — это письма, формируемые в результате коллаборативной работы над документами. Зачастую они содержат как оргинал текста, так и его редакцию. Например, письма с diff'ами, рассылаемые Confluence при редактировании крупных документов, легко могут достигать нескольких сотен килобайт форматированного текста.
UFO just landed and posted this here
Спасибо, это опечатка. Имелась в виду компания CloudMouse. Поправили.
В статье опечатка, речь идет про историю CloudMouse
Если поискать на Habr
UFO just landed and posted this here
Довольно неплохо разобран типовой отказ Ceph тут
Основная проблема Ceph – плохая прогнозируемость эксплуатации. Строить коммерческие системы на нем можно, точно понимая что делать во время отказа и имея в запасе инженерную команду, способную эти проблемы чинить на уровне кода.
Это совсем другая модель и компаниям, которые не занимаются разработкой системного ПО такой подход не годится.
Sign up to leave a comment.
Как мы создаём почтовую систему нового поколения Mailion. Эффективное объектное хранилище для электронной почты