Здравствуйте, gandjustas, Вы писали:
g> AB>Объемы данных для HBase исчисляются в петабайтах — время восстановления из бэкапа будет исчисляться неделями, что неприемлемо, т.к. даже сутки простоя подобных баз нанесут ущерб сопоставимый с увеличением фактора репликации на несколько единиц. g> Тем не менее вопрос остается открытым. Если случилась катастрофа, то как восстановить работу?
Ну у меня в этом случае данные перезальются с соседнего дата-центра. Будет долго, но downtime самого сервиса будет нулевой, т.к. вся нагрузка перераспределится на рабочие кластера.
g> Да и петабайты на HBase мало интересуют. Больше интересуют системы, которые позиционируются как замена РСУБД.
Так вроде NoSQL и не позиционируется как замена РСУБД — они решают свой класс задач, где использование "классических" БД становится затратным/неудобным.
g> AB>P.S. 20TB за 28h => 208MB/s на дисковую подсистему или 1.74 Gb/s на сеть. Для обычного оборудования это уже слишком быстро, для хорошего сильно медленно. g> Это был тестовый рестор на машинку с обычными дисками.
Т.е. бэкап не тянулся с хранилища по сети, а лежал локально?
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, gandjustas, Вы писали:
g>> AB>Объемы данных для HBase исчисляются в петабайтах — время восстановления из бэкапа будет исчисляться неделями, что неприемлемо, т.к. даже сутки простоя подобных баз нанесут ущерб сопоставимый с увеличением фактора репликации на несколько единиц. g>> Тем не менее вопрос остается открытым. Если случилась катастрофа, то как восстановить работу? AB>Ну у меня в этом случае данные перезальются с соседнего дата-центра. Будет долго, но downtime самого сервиса будет нулевой, т.к. вся нагрузка перераспределится на рабочие кластера.
А что делать в случае прикладной ошибки и кто-то порушил данные?
g>> Да и петабайты на HBase мало интересуют. Больше интересуют системы, которые позиционируются как замена РСУБД. AB>Так вроде NoSQL и не позиционируется как замена РСУБД — они решают свой класс задач, где использование "классических" БД становится затратным/неудобным.
Cassandra, Mongo и несколькодругих позиционируют себя именно как замена.
g>> AB>P.S. 20TB за 28h => 208MB/s на дисковую подсистему или 1.74 Gb/s на сеть. Для обычного оборудования это уже слишком быстро, для хорошего сильно медленно. g>> Это был тестовый рестор на машинку с обычными дисками. AB>Т.е. бэкап не тянулся с хранилища по сети, а лежал локально?
Конечно с хранилища по сети. Но в локалке скорость сильно выше, чем скорость дисков.
Здравствуйте, gandjustas, Вы писали:
g> AB>Ну у меня в этом случае данные перезальются с соседнего дата-центра. Будет долго, но downtime самого сервиса будет нулевой, т.к. вся нагрузка перераспределится на рабочие кластера. g> А что делать в случае прикладной ошибки и кто-то порушил данные?
То же самое. Кластер сконфигурирован таким образом, чтобы можно было пережить полный отказ одного дата-центра без прекращения работы сервиса. Плюс потенциально деструктивные изменения сначала тестируются на тестовом стенде, а потом какое-то время на prestable с боевой нагрузкой и данными. Дополнительно данные никогда сразу не удаляются (или просто никогда не удаляются в зависимости от).
g> g>> AB>P.S. 20TB за 28h => 208MB/s на дисковую подсистему или 1.74 Gb/s на сеть. Для обычного оборудования это уже слишком быстро, для хорошего сильно медленно. g> g>> Это был тестовый рестор на машинку с обычными дисками. g> AB>Т.е. бэкап не тянулся с хранилища по сети, а лежал локально? g> Конечно с хранилища по сети. Но в локалке скорость сильно выше, чем скорость дисков.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, gandjustas, Вы писали:
g>> AB>Ну у меня в этом случае данные перезальются с соседнего дата-центра. Будет долго, но downtime самого сервиса будет нулевой, т.к. вся нагрузка перераспределится на рабочие кластера. g>> А что делать в случае прикладной ошибки и кто-то порушил данные?
AB>То же самое. Кластер сконфигурирован таким образом, чтобы можно было пережить полный отказ одного дата-центра без прекращения работы сервиса. Плюс потенциально деструктивные изменения сначала тестируются на тестовом стенде, а потом какое-то время на prestable с боевой нагрузкой и данными. Дополнительно данные никогда сразу не удаляются (или просто никогда не удаляются в зависимости от).
То есть репликация не автоматическая? Или есть еще отдельный тестовый стенд?
g>> g>> AB>P.S. 20TB за 28h => 208MB/s на дисковую подсистему или 1.74 Gb/s на сеть. Для обычного оборудования это уже слишком быстро, для хорошего сильно медленно. g>> g>> Это был тестовый рестор на машинку с обычными дисками. g>> AB>Т.е. бэкап не тянулся с хранилища по сети, а лежал локально? g>> Конечно с хранилища по сети. Но в локалке скорость сильно выше, чем скорость дисков. AB>Локалка с 10 гигабитным линком?
Да
Здравствуйте, gandjustas, Вы писали:
g> То есть репликация не автоматическая? Или есть еще отдельный тестовый стенд?
Есть отдельный тестовый стенд для каждого компонента. Репликация автоматическая в рамках одного ДЦ (cross-dc очень дорого гонять большой трафик, по этому они получаются изолированными).
g> AB>Локалка с 10 гигабитным линком? g> Да
CK>>Ну так можно восстановить все из снепшота, что в этом непонятного? G>Ты вроде писал, что снепшот не хранит данные? Или таки хранит?
Данные в HDFS хранятся в блоках (128Мб по умолчанию), каждый файл это набор блоков, файлы — append only (блоки не изменяются) и каждый блок живет ровно до тех пор, пока на него ссылается хоть один снепшот. Снепшотятся метаданные, т.е. маппинг обектов файловой системы на блоки HDFS (содержимое name серверов). Соответственно, все что угодно можно восстановить из снепшота, ведь данные не удаляются пока жив снепшот. Снепшоты в HBase построены на основе снепшотов HDFS
CK>>Так и бэкап твой тоже ничего не гарантирует. G>В смысле? Из бекапа можно восстановить базу в предыдущем состоянии.
Сервер на котором хранятся бэкапы тоже не абсолютно надежен. Вот представь, хранишь ты бэкапы в дисковой полке, но когда полку только купили, какой-нибудь идиот-админ взял и объединил все дисковое пространство в одну файловую систему, а незадолго до того как тебе потребовалось восстановить базу из бэкапа произошел переезд в другой ДЦ, полка была перезапущена неаккуратно и начала выполнять fcheck. Я не знаю сколько точно длится fcheck файловой системы размером в 360ТБ, но готов поспорить что дольше недели. Я такой факап видел, в полке хранились в том числе и бэкапы БД, хорошо что они не потребовались.
Опять же, если принять во внимание bit rot. Вот лежит у тебя несколько десятков ТБ бэкапов, ты уверен что из них можно восстановить БД в любой момент? А вдруг там какой-нибудь сектор уже не читается? Насколько я знаю, NTFS не хранит контрольные суммы секторов/блоков (как и ext4 и многие другие файловые системы), поэтому я даже не знаю, можно ли проверить integrity бэкапа в этом вашем MSSQL. Мне кажется, хорошим выходом из этой ситуации будет хранение бэкапов MSSQL в HDFS. HDFS считает и хранит контрольные суммы
G>Потому что репликация требует серверов, а бекап только хранилища. Потому что бекап жмется, а реплика не всегда. Потому что бекапов достаточно трех в разных местах, а реплик бывает трех недостаточно.
Я уже писал что данные в HBase жмутся лучше чем в большинстве РСУБД. И реплик больше трех нужно для того, чтобы данные не копировать туда сюда, если нужно запустить развесистый MapReduce Job!
G>Кто вам глупость такую сказал. Log shipping уже 11 лет (а может и больше) позволяет делать геораспределенную реплику.
Я совершенно искренне заблуждался на этот счет!
CK>>Как можно сравнивать? К тому же, следует понимать разницу между бэкапом и репликацией, неужели для тебя это все одно и тоже? G>Я понимаю разницу, и понимаю что ты используешь репликацию вместо бекапа, потому что с бекапом (вернее с рестором) у NoSQL обычно плохо все.
Ну что значит обычно? У какого-нибудь Redis-a может и плохо, я не эксплуатировал его, не знаю. Но вот у HBase/Cassandra и много чего еще — все очень хорошо. В HBase снепшоты накатываются без даунтайма практически.
CK>>Данные страшно потерять. Но, помимо этого, страшно потерять инфраструктуру, посчитанные на основе данных аггрегаты (т.к. их месяц придется пересчитывать), страшно потерять работающие MapReduce задачи, которые очень долго выполняются и все такое. G>Ты написал что данные можно восстановить из других источников. Значит не так страшно.
Нет, я пытался сказать, что важны не столько данные сами по себе, сколько процессы, которые потребляют и производят данные. Инфраструктура и все такое. И если восстановить данные из бэкапа — несложно, то поднять заново всю инфраструктуру и заставить ее работать — очень проблематично. Поэтому полная реплика в другом ДЦ — вещь оправданная, т.к. она готова к работе. Просто покупаем надежность ценой избыточности инфраструктуры.
CK>>Это разумное время по твоему? G>Более чем разумное. В твоем случае какое время восстановления будет если ДЦ взорвется? Есть подозрение, что реплика того же объема по сети из другого ДЦ будет тянуться гораздо дольше, да еще и стоить реплика будет сильно дороже чем бекап на ленте.
CK>Опять же, если принять во внимание bit rot. Вот лежит у тебя несколько десятков ТБ бэкапов, ты уверен что из них можно восстановить БД в любой момент? А вдруг там какой-нибудь сектор уже не читается? Насколько я знаю, NTFS не хранит контрольные суммы секторов/блоков (как и ext4 и многие другие файловые системы), поэтому я даже не знаю, можно ли проверить integrity бэкапа в этом вашем MSSQL.
NTFS не хранит, т.к. CRC и ECC по факту уже реализованы внутри самого диска. Bit rot детектится хард драйвом ещё до того, как данные попадут на уровень файловой системы. Более того, благодаря ECC, они сначала корректируются, блок релокируется, и только когда запасных блоков для релокации перестаёт хватать или объём повреждений сектора превышает возможности ECC, мы получаем сбой чтения, заметный на уровне ФС.
Bottom line: прочитать "гнилые данные" с современного винта практически невозможно.
CK>Нет, я пытался сказать, что важны не столько данные сами по себе, сколько процессы, которые потребляют и производят данные. Инфраструктура и все такое. И если восстановить данные из бэкапа — несложно, то поднять заново всю инфраструктуру и заставить ее работать — очень проблематично. Поэтому полная реплика в другом ДЦ — вещь оправданная, т.к. она готова к работе. Просто покупаем надежность ценой избыточности инфраструктуры.
Это кстати вообще, на мой взгляд, общее место какое-то. Т.е. к примеру крайне популярна тема сравнения надёжности (fault tolerance) и доступности (availability) разных решений — SQL там, NoSQL, и т.п. — при этом, что характерно, никаких разговоров о времени восстановления из бэкапа не ведётся в принципе. На мой взгляд, это профанация — потому, что двухмашинный active-passive кластер при смерти активной ноды превращается в одномашинный кластер. Если восстановление второй ноды занимает неделю, то у нас есть все шансы нарваться на второй фолт и получить полную потерю данных.
В SQL Azure, насколько я знаю, по этой причине используется три реплики базы, и коммит требует кворума "2 из 3х". Благодаря этому при единичном сбое мы всё ещё имеем избыточность, и можно продолжать работать. Если у нас осталась единственная реплика данных, то по идее надо всё тихонечко выключать и молиться, что за время подготовки второй реплики в первую не шарахнет метеорит
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>NTFS не хранит, т.к. CRC и ECC по факту уже реализованы внутри самого диска. Bit rot детектится хард драйвом ещё до того, как данные попадут на уровень файловой системы. Более того, благодаря ECC, они сначала корректируются, блок релокируется, и только когда запасных блоков для релокации перестаёт хватать или объём повреждений сектора превышает возможности ECC, мы получаем сбой чтения, заметный на уровне ФС.
А ZFS видимо просто так придумали?
Это опасное заблуждение. Данные портятся и могут быть восстановлены контроллером используя CRC и ECC только в том случае, если их кто-нибудь читает! Вот именно для этого и придумали data scrubbing, если что. Если ты не читаешь испорченный сектор годами, то ошибки в нем накапливаются и его уже нельзя восстановить, при попытке чтения ты получишь URE или, что еще хуже, прочитаешь битый сектор.
S>Bottom line: прочитать "гнилые данные" с современного винта практически невозможно.
Даже из RAID-5 массива их можно прочитать.
S>Это кстати вообще, на мой взгляд, общее место какое-то. Т.е. к примеру крайне популярна тема сравнения надёжности (fault tolerance) и доступности (availability) разных решений — SQL там, NoSQL, и т.п. — при этом, что характерно, никаких разговоров о времени восстановления из бэкапа не ведётся в принципе. На мой взгляд, это профанация — потому, что двухмашинный active-passive кластер при смерти активной ноды превращается в одномашинный кластер. Если восстановление второй ноды занимает неделю, то у нас есть все шансы нарваться на второй фолт и получить полную потерю данных. S>В SQL Azure, насколько я знаю, по этой причине используется три реплики базы, и коммит требует кворума "2 из 3х". Благодаря этому при единичном сбое мы всё ещё имеем избыточность, и можно продолжать работать. Если у нас осталась единственная реплика данных, то по идее надо всё тихонечко выключать и молиться, что за время подготовки второй реплики в первую не шарахнет метеорит
Термин "high-availability" подразумевает что твой кластер может пережить потерю до трети машин без перерывов в обслуживании. С двухмашинным "кластером" ни о каком HA говорить, само собой, нельзя. Если под "репликами" подразумеваются разные кластеры в двух разных ДЦ, то да, после того как в первый ДЦ шарахнул метеорит, второй будет работать без реплики. Но мы тут исходим из того, что событие "метеорит шарахнул в ДЦ" — очень маловероятно.
Здравствуйте, chaotic-kotik, Вы писали: CK>Это опасное заблуждение. Данные портятся и могут быть восстановлены контроллером используя CRC и ECC только в том случае, если их кто-нибудь читает! Вот именно для этого и придумали data scrubbing, если что. Если ты не читаешь испорченный сектор годами, то ошибки в нем накапливаются и его уже нельзя восстановить, при попытке чтения ты получишь URE или, что еще хуже, прочитаешь битый сектор.
А можно пояснить, каким именно образом мне удастся прочитать битый сектор? С учётом CRC на уровне контроллера.
CK>Даже из RAID-5 массива их можно прочитать.
Пруфлинк в студию.
CK>Термин "high-availability" подразумевает что твой кластер может пережить потерю до трети машин без перерывов в обслуживании.
Откуда такое определение? Сами придумали? Термин availability означает процент времени работы, в течение которого система остаётся доступной. High availability — термин неформальный, означает просто "высокий процент доступности". Каким способом он досигается — вопрос вторичный. Можно брать более качественные компоненты, можно закладывать избыточность прямо внутрь отдельной машины (например, дублируют блок питания), можно увеличивать количество машин в кластере.
CK>С двухмашинным "кластером" ни о каком HA говорить, само собой, нельзя. Если под "репликами" подразумеваются разные кластеры в двух разных ДЦ, то да, после того как в первый ДЦ шарахнул метеорит, второй будет работать без реплики. Но мы тут исходим из того, что событие "метеорит шарахнул в ДЦ" — очень маловероятно.
Ок, попробую на пальцах вам объяснить сложную для вас вещь: даже в вашем надуманном определении, кластер из трех машин считается HA. Но как только одна из них навернулась, кластер тут же перестал быть HA, так как в нём осталось только две машины. Этот момент понятен, или нужно дальше объяснять?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>А можно пояснить, каким именно образом мне удастся прочитать битый сектор? С учётом CRC на уровне контроллера.
Я же написал как. CRC защищает от небольших повреждений (bit flip). В этом случае контроллер может попереворачивать биты сверяя CRC, но этот процесс не гарантирует ничего на 100%. Как минимум, может повредиться сама контрольная сумма. Как максимум — несколько повреждений в одном секторе гарантированно приведут к URE.
CK>>Даже из RAID-5 массива их можно прочитать. S>Пруфлинк в студию.
google -> "RAID5 URE"
CK>>Термин "high-availability" подразумевает что твой кластер может пережить потерю до трети машин без перерывов в обслуживании. S>Откуда такое определение? Сами придумали? Термин availability означает процент времени работы, в течение которого система остаётся доступной. High availability — термин неформальный, означает просто "высокий процент доступности". Каким способом он досигается — вопрос вторичный. Можно брать более качественные компоненты, можно закладывать избыточность прямо внутрь отдельной машины (например, дублируют блок питания), можно увеличивать количество машин в кластере.
Из CAP. HA система, это практически всегда AP система, которой, для того чтобы пережить F fail-stop отказов нужно 2F + 1 машин. Про "треть" машин я написал подразумевая трехмашинную конфигурацию (о которой шла речь). Высокая доступность тут достигается за счет кворума и избыточности. За счет одних только железок достижение высокой доступности едва ли возможно. Поэтому люди и обсуждают availability и fault-tolerance в одном контексте, так как первое достигается за счет второго даже на ширпотребном железе. Доступность на разных уровнях означает разное, дополнительный блок питания это хорошо, RAID массив тоже хорошо, но если я пытаюсь записать данные в БД и запрос отваливается по таймауту, считается что система недоступна в данный момент, это даунтайм. А это может быть даже если все железо работает хорошо, никаких железных отказов не было даже близко. Ну например CP система словила split-brain из-за GC-паузы. Split-brain длился пять секунд но в течении этих пяти секунд система была недоступна на запись.
S>Ок, попробую на пальцах вам объяснить сложную для вас вещь: даже в вашем надуманном определении, кластер из трех машин считается HA. Но как только одна из них навернулась, кластер тут же перестал быть HA, так как в нём осталось только две машины. Этот момент понятен, или нужно дальше объяснять?
Про hot standby слышал, или троллинг в интернете все свободное время занимает?
Здравствуйте, chaotic-kotik, Вы писали:
CK>Я же написал как. CRC защищает от небольших повреждений (bit flip). В этом случае контроллер может попереворачивать биты сверяя CRC, но этот процесс не гарантирует ничего на 100%. Как минимум, может повредиться сама контрольная сумма. Как максимум — несколько повреждений в одном секторе гарантированно приведут к URE. CK>google -> "RAID5 URE"
Какое отношение URE имеют к прочтению побитых данных? Вы путаете CRC с ECC.
CK>Из CAP.
CAP — вообще булшит, простите за прямоту. "Научные" работы, которые оперируют термином Availability в смысле "она есть либо нету", нужно сразу скармливать в шредер.
Нормальные инженеры оперируют процентом аптайма. Реальные системы никогда не смогут получить 100% аптайм. Для понимания этого не надо защищать докторские диссертации или доказывать теоремы.
Инженерам формальное доказательство тезиса "железу свойственно ломаться" неинтересно. Инженерам интересно, как получить систему с availability = 99.99% из компонентов с availability = 99%.
Именно поэтому все рассуждения про построение HA без обсуждения time to recover — булшит и профанация.
В частности, в CAP про это нету ничего, кроме упоминания во введении. В стиле "но, поскольку это слишком сложно, то в данной работе заниматься этим мы не будем".
CK>Про hot standby слышал, или троллинг в интернете все свободное время занимает?
Конечно слышал. Делать вид, что standby оборудование не является частью вашей HA-конфигурации — опять профанация.
То есть если у вас трёхмашинный HA-кластер, и есть четвёртая машина в hot standby, то у вас четырёхмашинная конфигурация. И точно так же, при единичном сбое, она превращается в "обычную" HA-конфигурацию, которая точно такая же, только без hot standby.
Более того, hot standby уменьшит MTTR только на время подготовки новой машины. Это актуально, если ваши процессы ввода в эксплуатацию построены на заказе сервера в Dell и его физической доставке и установке. Если у вас процесс ввода новой машинки в эксплуатацию построен на EC2-стиле, а сами машинки — stateful, то MTTR будет определяться временем репликации данных, и использование hot standby будет противопоказано.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Приятно почитать мнения людей знающих специфику NoSQL и RDBMS.
Простите за оффтоп, я с шароварного форума, и возможно вам будет интересно мое приложение http://www.mongodbmanager.com/
С меня бесплатные ключи, от вас пожелания и замечания.
CK>>Я же написал как. CRC защищает от небольших повреждений (bit flip). В этом случае контроллер может попереворачивать биты сверяя CRC, но этот процесс не гарантирует ничего на 100%. Как минимум, может повредиться сама контрольная сумма. Как максимум — несколько повреждений в одном секторе гарантированно приведут к URE. CK>>google -> "RAID5 URE" S>Какое отношение URE имеют к прочтению побитых данных? Вы путаете CRC с ECC.
2.3 Corruption Classes
This study focuses on disk block corruptions caused by both hardware and
software errors. Hardware bugs include bugs in the disk drive or the disk
shelf firmware, bad memory, and adapter failures. Software bugs could also
cause some corruption. In many cases, the cause of corruption cannot be
identified. We detect different forms of corruption using the different data
protection mechanisms in place. As mentioned earlier, we distinguish be-
tween these forms in our study. Table I gives a summary of these corruption
classes.
—
Checksum Mismatches (CMs). This corruption class refers to cases where the
corruption is detected from mismatched data and checksum. The cause could
be: (i) data content corrupted by components within the data path; (ii) a torn
write, wherein only a portion of the data block is written successfully; or (iii)
a misdirected write, wherein the data is written to either the wrong disk or
the wrong location on disk, thus overwriting and corrupting data [Bartlett
and Spainhower 2004; Prabhakaran et al. 2005]. Checksum mismatches can
be detected anytime a disk block is read (file system reads, data scrubs, RAID
reconstruction, and so on).
—
Identity Discrepancies (IDs). This corruption class refers to a mismatch de-
tected when a disk block identity check is performed during a file system
read. The cause could be: (i) a lost write, which typically occurs because a
write destined for disk is not written but thought of as written; or (ii) a mis-
directed write, where the original disk location is not updated. We are aware
of actual cases when the disk firmware replied successfully to a write that
ACM Transactions on Storage, Vol. 4, No. 3, Article 8, Publication date: November 2008.
An Analysis of Data Corruption in the Storage Stack was never written to stable media.
Identity discrepancies can be detected only during file system reads.
—
Parity Inconsistencies (PIs): This corruption class refers to a mismatch be-
tween the parity computed from data blocks and the parity stored on disk
despite the individual checksums being valid. This error could be caused
by lost or misdirected writes, in-memory corruptions, processor miscalcula-
tions, and software bugs. Parity inconsistencies are detected only during data
scrub
S>CAP — вообще булшит, простите за прямоту. "Научные" работы, которые оперируют термином Availability в смысле "она есть либо нету", нужно сразу скармливать в шредер. S>Нормальные инженеры оперируют процентом аптайма. Реальные системы никогда не смогут получить 100% аптайм. Для понимания этого не надо защищать докторские диссертации или доказывать теоремы.
Инженерам следовало бы прочитать и разобрать хоть одну научную статью на эту тему. В CAP не ведется речь ни о каких реальных системах, там в качестве хранилища используется один регистр, вместо сети — асинхронная модель сети и тд.
S>Инженерам формальное доказательство тезиса "железу свойственно ломаться" неинтересно. Инженерам интересно, как получить систему с availability = 99.99% из компонентов с availability = 99%. S>Именно поэтому все рассуждения про построение HA без обсуждения time to recover — булшит и профанация. S>В частности, в CAP про это нету ничего, кроме упоминания во введении. В стиле "но, поскольку это слишком сложно, то в данной работе заниматься этим мы не будем".
Наверное потому что CAP вообще не про это. Обычно с ее помощью рассуждают о линеаризуемости. Какое отношение к этому имеют твои 99.99% аптайма — тайна покрытая мраком. Можно иметь 100% аптайм, но не иметь возможности получить или записать данные. А CAP как раз про гарантию возможности сделать что-либо. Если система не линеаризуема, то никакой аптайм не даст тебе возможность получить целостную картину данных в любой момент времени. Как-то так.
S>Конечно слышал. Делать вид, что standby оборудование не является частью вашей HA-конфигурации — опять профанация. S>То есть если у вас трёхмашинный HA-кластер, и есть четвёртая машина в hot standby, то у вас четырёхмашинная конфигурация. И точно так же, при единичном сбое, она превращается в "обычную" HA-конфигурацию, которая точно такая же, только без hot standby.
Не буду спорить, мне кажется, в мире абсолютно надежных жестких дисков все действительно может быть так
S>Более того, hot standby уменьшит MTTR только на время подготовки новой машины. Это актуально, если ваши процессы ввода в эксплуатацию построены на заказе сервера в Dell и его физической доставке и установке. Если у вас процесс ввода новой машинки в эксплуатацию построен на EC2-стиле, а сами машинки — stateful, то MTTR будет определяться временем репликации данных, и использование hot standby будет противопоказано.
В "ЕС2-стиле" это когда spot инстансы автоматически provision-ятся самим приложением на основе текущей нагрузки, прогноза и текущих цен? Ну да, действительно не очень актуально
Здравствуйте, 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-ятся самим приложением на основе текущей нагрузки, прогноза и текущих цен?
Нет, это когда монитор, замечающий выход ноды из строя, автоматически поднимает новую с аналогичной конфигурацией. Для приложения это полностью прозрачно и ничем не отличается от выезда админа с запасным юнитом на место хостинга.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Не надо цитировать простыни. Надо просто понять, что для детектирования невалидности бэкапа контрольные суммы на уровне ФС не нужны. Достаточно контрольных сумм на уровне контроллера диска. S>Точно так же, как нет смысла впихивать контрольные суммы в сетевой протокол, работающий поверх TCP.
Объясни тогда, зачем ZFS, Btrfs, Postgres (начиная с 9.3 кажется), тот же Hadoop, да что угодно вообще — считают чексуммы для страниц/блоков? Вот я тут привел ссылку на исследование подтверждающее мои слова, на что ты ответил — "не надо цитировать простыни" "надо просто понять"! Это просто потрясающе, аплодирую стоя! Сам же до этого просил ссылку привести
CK>>Инженерам следовало бы прочитать и разобрать хоть одну научную статью на эту тему. В CAP не ведется речь ни о каких реальных системах, там в качестве хранилища используется один регистр, вместо сети — асинхронная модель сети и тд. S>Вот и я об этом. Я, собственно, про CAP читал в первоисточнике.
Да нет, ты не об этом писал, ты писал про то что CAP — булшит. Хотя очевидно, что человек, который читал и понимает, осознает ее применимость.
CK>>Наверное потому что CAP вообще не про это. Обычно с ее помощью рассуждают о линеаризуемости. S>Тогда зачем вы тащите её в рассуждения об availability?
Потому что тема называется "Выбор NoSQL".
CK>>Можно иметь 100% аптайм, но не иметь возможности получить или записать данные. S>Нет, нельзя. По определению.
Надо просто понять ((c) Sinclair), что запрос на запись может отвалиться по таймауту даже если с железом все ОК, нет ошибок конфигурации и всего такого.
S>>>То есть если у вас трёхмашинный HA-кластер, и есть четвёртая машина в hot standby, то у вас четырёхмашинная конфигурация. И точно так же, при единичном сбое, она превращается в "обычную" HA-конфигурацию, которая точно такая же, только без hot standby. CK>>Не буду спорить, мне кажется, в мире абсолютно надежных жестких дисков все действительно может быть так S>При чём тут абсолютная надёжность? Мы говорим ровно про ненадёжное железо и способы борьбы с этой ненадёжностью. В мире абсолютно надёжных жёстких дисков даже одна нода будет highly available.
Ну это шутка была. Ну просто я не знаю как можно это всерьез обсуждать. Можно наверное было поговорить о том, что машина у меня на самом деле — пяти колесная, ведь я всегда вожу запаску в багажнике! А при единичном сбое машина превращается в 4х колесную, она уже не HA, пока запаску обратно не положишь. Это я к тому, что все это — пустое словоблудство. Я тут вообще про кластер из ~100 машин рассказывал, с которым доводилось работать, откуда вообще взялась эта трех машинная конфигурация в обсуждении?
Здравствуйте, chaotic-kotik, Вы писали: CK>Объясни тогда, зачем ZFS, Btrfs, Postgres (начиная с 9.3 кажется), тот же Hadoop, да что угодно вообще — считают чексуммы для страниц/блоков?
Не знаю. Судя по официальным докам, в SQL Server нет чексумм для страниц, что не мешает ему входить в тройку лидеров.
В процитированной вами части работы написано, что checksum помогает отловить ошибки сбоя записи. И, что "Checksum mismatches can be detected anytime a disk block is read".
CK>Вот я тут привел ссылку на исследование подтверждающее мои слова
Я не вижу никакого подтверждения. К полному исследованию доступа у меня нет, в процитированной части нет ничего про то, что контроллер может "не заметить" сбой CRC при чтении данных. CK>Да нет, ты не об этом писал, ты писал про то что CAP — булшит. Хотя очевидно, что человек, который читал и понимает, осознает ее применимость.
Пока что я не видел применения CAP ни к чему, кроме рассуждений уровня "мы применяем NoSQL потому, что CAP".
CK>Потому что тема называется "Выбор NoSQL".
О, ну вот опять. NoSQL потому что CAP. Ещё раз поясню непонятную мне линию рассуждений: вы утверждаете, что High Availability — это возможность потерять до трети машин, потому что так вам рассказали в CAP. И следом же пишете, что CAP — она вообще не про availability.
А я вам пишу, что HA — это аптайм выше некоторого порога, например 99.99%. И потеря трети или четверти машин сама по себе ничего не значит, т.к. реальный процент аптайма будет зависеть от времени возврата их в строй.
CK>>>Можно иметь 100% аптайм, но не иметь возможности получить или записать данные. S>>Нет, нельзя. По определению. CK>Надо просто понять ((c) Sinclair), что запрос на запись может отвалиться по таймауту даже если с железом все ОК, нет ошибок конфигурации и всего такого.
У вас в голове явно есть одновременно два термина availability, с конфликтующими определениями. Availability означает способность выполнять запрошенные операции. То есть если операция отпала по таймауту — это значит, что система non-available. По определению. Поэтому невозможно иметь аvailability без возможности записи/чтения. А у вас получается "прибор работает, но не включается, потому что включается, но не работает".
CK>Ну это шутка была. Ну просто я не знаю как можно это всерьез обсуждать. Можно наверное было поговорить о том, что машина у меня на самом деле — пяти колесная, ведь я всегда вожу запаску в багажнике!
Запаска — плохой пример. Точнее, хороший пример плохой HA. Хороший пример — БТР. У него нет никаких запасок. Тем не менее, ему не страшны повреждения до трёх колёс (если с разных бортов) или 2х с одного.
Вот если бы мы обсуждали дизайн БТР, и вы бы мне впаривали шестиколёсную конфигурацию с двумя запасками (тот самый hot standby), то я бы парировал восьмиколёсной конфигурацией, т.к. она позволяет снизить нагрузку на каждую из шин и сделать их дешевле, при сохранении того же фактора избыточности.
CK>А при единичном сбое машина превращается в 4х колесную, она уже не HA, пока запаску обратно не положишь.
Конечно. А вы не знали? Или вы думали, что наличие запаски обеспечит вам 100% аптайм, независимо от времени ремонта пробитого колеса? Ну так вот нет, не обеспечит. Поэтому опытные собаководы берут с собой две запаски когда едут в такие места, где шиномонтаж занимает слишком много времени.
CK>Это я к тому, что все это — пустое словоблудство. Я тут вообще про кластер из ~100 машин рассказывал, с которым доводилось работать, откуда вообще взялась эта трех машинная конфигурация в обсуждении?
Она взялась из "минимальной HA" конфигурации. Вы же тут утверждали, что кластер из двух машин не является HA.
Ну давайте возьмём кластер из 300 машин. Предположим, MTBF у нас — 1 год, а MTTR = 1000 лет. Какова availability этого кластера при эксплуатации в течение неограниченного времени?
Возьмём двухмашинный кластер. Предположим, MTBF у нас по-прежнему 1 год, а MTTR — 5 минут. Какова availability этого кластера?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>NTFS не хранит, т.к. CRC и ECC по факту уже реализованы внутри самого диска.
Ког Зачем тогда ReFS? Плюс, CRC совершенно не спасает при "логических" ошибках, когда, например, данные уже обновились, а метаданные -- ещё нет.
S>Bit rot детектится хард драйвом ещё до того, как данные попадут на уровень файловой системы. Более того, благодаря ECC, они сначала корректируются, блок релокируется, и только когда запасных блоков для релокации перестаёт хватать или объём повреждений сектора превышает возможности ECC, мы получаем сбой чтения, заметный на уровне ФС.
Это если безгранично верить в безошибочность Firmware жестких дисков.
S>Bottom line: прочитать "гнилые данные" с современного винта практически невозможно.
...As another example, a real-life study performed by NetApp on more than 1.5 million HDDs over 41 months found more than 400,000 silent data corruptions, out of which more than 30,000 were not detected by the hardware RAID controller. Another study, performed by CERN over six months and involving about 97 petabytes of data, found that about 128 megabytes of data became permanently corrupted.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Нахлобуч, Вы писали: Н>Ког Зачем тогда ReFS? Плюс, CRC совершенно не спасает при "логических" ошибках, когда, например, данные уже обновились, а метаданные -- ещё нет.
Я думаю, что ReFS отрабатывает более широкий класс сценариев, чем "обнаружить повреждение блока данных на диске". Как я понял, там хотят устранить нужду в chkdsk, а не отловить ситуации, которые chkdsk отловить неспособен.
Н>Это если безгранично верить в безошибочность Firmware жестких дисков.
Это да. Помнится, ещё в 90х встречались китайские чипы памяти, у которых parity bit вычислялся на ходу .
S>>Bottom line: прочитать "гнилые данные" с современного винта практически невозможно.
Н>Однако же:
Там речь идёт об ошибках, которые не были вовремя замечены.
То есть опять не о том, что из контроллера приехал мусор, а о том, что диск протух три месяца назад, а узнали мы об этом только сегодня.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
. 