Здравствуйте, chaotic-kotik, Вы писали:

CK>>>Я же написал как. CRC защищает от небольших повреждений (bit flip). В этом случае контроллер может попереворачивать биты сверяя CRC, но этот процесс не гарантирует ничего на 100%. Как минимум, может повредиться сама контрольная сумма. Как максимум — несколько повреждений в одном секторе гарантированно приведут к URE.
CK>>>google -> "RAID5 URE"
S>>Какое отношение URE имеют к прочтению побитых данных? Вы путаете CRC с ECC.
Не надо цитировать простыни. Надо просто понять, что для детектирования невалидности бэкапа контрольные суммы на уровне ФС не нужны. Достаточно контрольных сумм на уровне контроллера диска.
Точно так же, как нет смысла впихивать контрольные суммы в сетевой протокол, работающий поверх TCP.

CK>Инженерам следовало бы прочитать и разобрать хоть одну научную статью на эту тему. В CAP не ведется речь ни о каких реальных системах, там в качестве хранилища используется один регистр, вместо сети — асинхронная модель сети и тд.
Вот и я об этом. Я, собственно, про CAP читал в первоисточнике.
CK>Наверное потому что CAP вообще не про это. Обычно с ее помощью рассуждают о линеаризуемости.
Тогда зачем вы тащите её в рассуждения об availability?

CK>Какое отношение к этому имеют твои 99.99% аптайма — тайна покрытая мраком.
Аптайм == availability. Сходите в википедию, что ли. Рассуждать о HA и не рассматривать аптайм — самообман и профанация.

CK>Можно иметь 100% аптайм, но не иметь возможности получить или записать данные.
Нет, нельзя. По определению.
CK> А CAP как раз про гарантию возможности сделать что-либо. Если система не линеаризуема, то никакой аптайм не даст тебе возможность получить целостную картину данных в любой момент времени. Как-то так.
Нам достаточно сериализуемости.

S>>То есть если у вас трёхмашинный HA-кластер, и есть четвёртая машина в hot standby, то у вас четырёхмашинная конфигурация. И точно так же, при единичном сбое, она превращается в "обычную" HA-конфигурацию, которая точно такая же, только без hot standby.
CK>Не буду спорить, мне кажется, в мире абсолютно надежных жестких дисков все действительно может быть так
При чём тут абсолютная надёжность? Мы говорим ровно про ненадёжное железо и способы борьбы с этой ненадёжностью. В мире абсолютно надёжных жёстких дисков даже одна нода будет highly available.

S>>Более того, hot standby уменьшит MTTR только на время подготовки новой машины. Это актуально, если ваши процессы ввода в эксплуатацию построены на заказе сервера в Dell и его физической доставке и установке. Если у вас процесс ввода новой машинки в эксплуатацию построен на EC2-стиле, а сами машинки — stateful, то MTTR будет определяться временем репликации данных, и использование hot standby будет противопоказано.

CK>В "ЕС2-стиле" это когда spot инстансы автоматически provision-ятся самим приложением на основе текущей нагрузки, прогноза и текущих цен?
Нет, это когда монитор, замечающий выход ноды из строя, автоматически поднимает новую с аналогичной конфигурацией. Для приложения это полностью прозрачно и ничем не отличается от выезда админа с запасным юнитом на место хостинга.