Сообщение Re[21]: Выбор NoSQL от 17.06.2016 9:53
Изменено 17.06.2016 9:56 chaotic-kotik
Здравствуйте, Sinclair, Вы писали:
S>Не знаю. Судя по официальным докам, в SQL Server нет чексумм для страниц, что не мешает ему входить в тройку лидеров.
В тройку лидеров чего?
S>В процитированной вами части работы написано, что checksum помогает отловить ошибки сбоя записи. И, что "Checksum mismatches can be detected anytime a disk block is read".
Pdf-ка статьи гуглится по названию, если что. Я не утверждаю что checksum mismatch нельзя отловить, я лишь утверждаю что не всегда можно восстановить блок (получится URE) и иногда данные просто теряются и ошибка на стороне диска не детектится (тут и ошибки в прошивке и не ECC память на борту некоторых HDD и возможно даже крайне редкие события, вроде такого изменения блока, после которого контрольная сумма сойдется).
S>О, ну вот опять. NoSQL потому что CAP. Ещё раз поясню непонятную мне линию рассуждений: вы утверждаете, что High Availability — это возможность потерять до трети машин, потому что так вам рассказали в CAP. И следом же пишете, что CAP — она вообще не про availability.
Нет, я не утверждаю что это возможность потерять до трети машин. Я говорил про availability в другом контексте.
S>У вас в голове явно есть одновременно два термина availability, с конфликтующими определениями. Availability означает способность выполнять запрошенные операции. То есть если операция отпала по таймауту — это значит, что система non-available. По определению. Поэтому невозможно иметь аvailability без возможности записи/чтения. А у вас получается "прибор работает, но не включается, потому что включается, но не работает".
Вот самое распространенное определение того, что есть availability (из CAP) — "Every request received by a non-failing node in the system must result in a response." (и под response тут имеется ввиду не возврат кода ошибки а ответ о том что все ОК). Это свойство системы, которое заключается в том, что на каждый запрос приходит ответ (если запрос дошел до работающей ноды). Заметь, что свойство никуда не пропадает, если часть машин недоступны. Если мы имеем дело с CP системой (Zookeeper например), то в случае отсутствия кворума мы не сможем ничего сделать (только читать протухшие данные). Если мы имеем дело с AP системой, например с Dinamo — данные будут записаны несмотря ни на что, даже если узел, принявший наш запрос вообще отсоединен от кластера, просто когда он присоединится обратно и мы попробуем прочитать обратно то что было записано — получим конфликт. Это свойство системы не зависит от MTTR вообще никак. Если система является доступной, в нее можно записывать всегда.
Другое определение availability, с которым мне доводилось встречаться (и я думал что ты именно его имеешь ввиду) — это тупо то же самое что и аптайм. Тут мы действительно можем повысить availability поставив дополнительный блок питания, так как вероятность аппаратного сбоя снижается. Но я исхожу из того что а) это само собой разумеется б) в контексте NoSQL availability — свойство системы куда интереснее и полезнее, нежели availability — надежность системы.
При этот одно из второго никак не следует. Можно иметь 100% надежное железо, которое никогда не ломается, все машины кластера могут работать и быть сконфигурированы правильно, при этом система не будет доступной. Вот например Zookeeper кластер — все ноды работают, но часть из них — под высокой нагрузкой, поэтому половина транзакций отваливается. Но при этом с точки зрения надежности и аптайма все хорошо.
S>Она взялась из "минимальной HA" конфигурации. Вы же тут утверждали, что кластер из двух машин не является HA.
S>Ну давайте возьмём кластер из 300 машин. Предположим, MTBF у нас — 1 год, а MTTR = 1000 лет. Какова availability этого кластера при эксплуатации в течение неограниченного времени?
S>Возьмём двухмашинный кластер. Предположим, MTBF у нас по-прежнему 1 год, а MTTR — 5 минут. Какова availability этого кластера?
Это все понятно, я не спорю с тем что время восстановления после сбоя — важно. Но вот подобные рассуждения про профанации, когда ты используешь тот же MTTR для доказательства, это очень странно. Это же среднее значение, т.е. ни о чем вообще. Вот например эксплуатируем кластер из 3х машин. У нас было два сбоя, первый сбой вылечился простой перезагрузкой за одну минуту, второй сбой — аппаратный, пришлось ждать новый сервер неделю. Какой будет MTTR и будет ли он иметь хоть какой-то практический смысл?
S>Не знаю. Судя по официальным докам, в SQL Server нет чексумм для страниц, что не мешает ему входить в тройку лидеров.
В тройку лидеров чего?
S>В процитированной вами части работы написано, что checksum помогает отловить ошибки сбоя записи. И, что "Checksum mismatches can be detected anytime a disk block is read".
Pdf-ка статьи гуглится по названию, если что. Я не утверждаю что checksum mismatch нельзя отловить, я лишь утверждаю что не всегда можно восстановить блок (получится URE) и иногда данные просто теряются и ошибка на стороне диска не детектится (тут и ошибки в прошивке и не ECC память на борту некоторых HDD и возможно даже крайне редкие события, вроде такого изменения блока, после которого контрольная сумма сойдется).
S>О, ну вот опять. NoSQL потому что CAP. Ещё раз поясню непонятную мне линию рассуждений: вы утверждаете, что High Availability — это возможность потерять до трети машин, потому что так вам рассказали в CAP. И следом же пишете, что CAP — она вообще не про availability.
Нет, я не утверждаю что это возможность потерять до трети машин. Я говорил про availability в другом контексте.
S>У вас в голове явно есть одновременно два термина availability, с конфликтующими определениями. Availability означает способность выполнять запрошенные операции. То есть если операция отпала по таймауту — это значит, что система non-available. По определению. Поэтому невозможно иметь аvailability без возможности записи/чтения. А у вас получается "прибор работает, но не включается, потому что включается, но не работает".
Вот самое распространенное определение того, что есть availability (из CAP) — "Every request received by a non-failing node in the system must result in a response." (и под response тут имеется ввиду не возврат кода ошибки а ответ о том что все ОК). Это свойство системы, которое заключается в том, что на каждый запрос приходит ответ (если запрос дошел до работающей ноды). Заметь, что свойство никуда не пропадает, если часть машин недоступны. Если мы имеем дело с CP системой (Zookeeper например), то в случае отсутствия кворума мы не сможем ничего сделать (только читать протухшие данные). Если мы имеем дело с AP системой, например с Dinamo — данные будут записаны несмотря ни на что, даже если узел, принявший наш запрос вообще отсоединен от кластера, просто когда он присоединится обратно и мы попробуем прочитать обратно то что было записано — получим конфликт. Это свойство системы не зависит от MTTR вообще никак. Если система является доступной, в нее можно записывать всегда.
Другое определение availability, с которым мне доводилось встречаться (и я думал что ты именно его имеешь ввиду) — это тупо то же самое что и аптайм. Тут мы действительно можем повысить availability поставив дополнительный блок питания, так как вероятность аппаратного сбоя снижается. Но я исхожу из того что а) это само собой разумеется б) в контексте NoSQL availability — свойство системы куда интереснее и полезнее, нежели availability — надежность системы.
При этот одно из второго никак не следует. Можно иметь 100% надежное железо, которое никогда не ломается, все машины кластера могут работать и быть сконфигурированы правильно, при этом система не будет доступной. Вот например Zookeeper кластер — все ноды работают, но часть из них — под высокой нагрузкой, поэтому половина транзакций отваливается. Но при этом с точки зрения надежности и аптайма все хорошо.
S>Она взялась из "минимальной HA" конфигурации. Вы же тут утверждали, что кластер из двух машин не является HA.
S>Ну давайте возьмём кластер из 300 машин. Предположим, MTBF у нас — 1 год, а MTTR = 1000 лет. Какова availability этого кластера при эксплуатации в течение неограниченного времени?
S>Возьмём двухмашинный кластер. Предположим, MTBF у нас по-прежнему 1 год, а MTTR — 5 минут. Какова availability этого кластера?
Это все понятно, я не спорю с тем что время восстановления после сбоя — важно. Но вот подобные рассуждения про профанации, когда ты используешь тот же MTTR для доказательства, это очень странно. Это же среднее значение, т.е. ни о чем вообще. Вот например эксплуатируем кластер из 3х машин. У нас было два сбоя, первый сбой вылечился простой перезагрузкой за одну минуту, второй сбой — аппаратный, пришлось ждать новый сервер неделю. Какой будет MTTR и будет ли он иметь хоть какой-то практический смысл?
Re[21]: Выбор NoSQL
Здравствуйте, Sinclair, Вы писали:
S>Не знаю. Судя по официальным докам, в SQL Server нет чексумм для страниц, что не мешает ему входить в тройку лидеров.
В тройку лидеров чего?
S>В процитированной вами части работы написано, что checksum помогает отловить ошибки сбоя записи. И, что "Checksum mismatches can be detected anytime a disk block is read".
Pdf-ка статьи гуглится по названию, если что. Я не утверждаю что checksum mismatch нельзя отловить, я лишь утверждаю что не всегда можно восстановить блок (получится URE) и иногда данные просто теряются и ошибка на стороне диска не детектится (тут и ошибки в прошивке и не ECC память на борту некоторых HDD и возможно даже крайне редкие события, вроде такого изменения блока, после которого контрольная сумма сойдется).
S>О, ну вот опять. NoSQL потому что CAP. Ещё раз поясню непонятную мне линию рассуждений: вы утверждаете, что High Availability — это возможность потерять до трети машин, потому что так вам рассказали в CAP. И следом же пишете, что CAP — она вообще не про availability.
Нет, я не утверждаю что это возможность потерять до трети машин. Я говорил про availability в другом контексте.
S>У вас в голове явно есть одновременно два термина availability, с конфликтующими определениями. Availability означает способность выполнять запрошенные операции. То есть если операция отпала по таймауту — это значит, что система non-available. По определению. Поэтому невозможно иметь аvailability без возможности записи/чтения. А у вас получается "прибор работает, но не включается, потому что включается, но не работает".
Вот самое распространенное определение того, что есть availability (из CAP) — "Every request received by a non-failing node in the system must result in a response." (и под response тут имеется ввиду не возврат кода ошибки а ответ о том что все ОК). Это свойство системы, которое заключается в том, что на каждый запрос приходит ответ (если запрос дошел до работающей ноды). Заметь, что свойство никуда не пропадает, если часть машин недоступны. Если мы имеем дело с CP системой (Zookeeper например), то в случае отсутствия кворума мы не сможем ничего сделать (только читать протухшие данные). Если мы имеем дело с AP системой, например с Dinamo — данные будут записаны несмотря ни на что, даже если узел, принявший наш запрос вообще отсоединен от кластера, просто когда он присоединится обратно и мы попробуем прочитать обратно то что было записано — получим конфликт. Это свойство системы не зависит от MTTR вообще никак. Если система является доступной, в нее можно записывать всегда.
Другое определение availability, с которым мне доводилось встречаться (и я думал что ты именно его имеешь ввиду) — это тупо то же самое что и аптайм. Тут мы действительно можем повысить availability поставив дополнительный блок питания, так как вероятность аппаратного сбоя снижается. Но я исхожу из того что а) это само собой разумеется б) в контексте NoSQL availability — свойство системы куда интереснее и полезнее, нежели availability — надежность системы.
При этом одно из второго никак не следует. Можно иметь 100% надежное железо, которое никогда не ломается, все машины кластера могут работать и быть сконфигурированы правильно, при этом система не будет доступной. Вот например Zookeeper кластер — все ноды работают, но часть из них — под высокой нагрузкой, поэтому половина транзакций отваливается. Но при этом с точки зрения надежности и аптайма все хорошо.
S>Она взялась из "минимальной HA" конфигурации. Вы же тут утверждали, что кластер из двух машин не является HA.
S>Ну давайте возьмём кластер из 300 машин. Предположим, MTBF у нас — 1 год, а MTTR = 1000 лет. Какова availability этого кластера при эксплуатации в течение неограниченного времени?
S>Возьмём двухмашинный кластер. Предположим, MTBF у нас по-прежнему 1 год, а MTTR — 5 минут. Какова availability этого кластера?
Это все понятно, я не спорю с тем что время восстановления после сбоя — важно. Но вот подобные рассуждения про профанации, когда ты используешь тот же MTTR для доказательства, это очень странно. Это же среднее значение, т.е. ни о чем вообще. Вот например эксплуатируем кластер из 3х машин. У нас было два сбоя, первый сбой вылечился простой перезагрузкой за одну минуту, второй сбой — аппаратный, пришлось ждать новый сервер неделю. Какой будет MTTR и будет ли он иметь хоть какой-то практический смысл?
S>Не знаю. Судя по официальным докам, в SQL Server нет чексумм для страниц, что не мешает ему входить в тройку лидеров.
В тройку лидеров чего?
S>В процитированной вами части работы написано, что checksum помогает отловить ошибки сбоя записи. И, что "Checksum mismatches can be detected anytime a disk block is read".
Pdf-ка статьи гуглится по названию, если что. Я не утверждаю что checksum mismatch нельзя отловить, я лишь утверждаю что не всегда можно восстановить блок (получится URE) и иногда данные просто теряются и ошибка на стороне диска не детектится (тут и ошибки в прошивке и не ECC память на борту некоторых HDD и возможно даже крайне редкие события, вроде такого изменения блока, после которого контрольная сумма сойдется).
S>О, ну вот опять. NoSQL потому что CAP. Ещё раз поясню непонятную мне линию рассуждений: вы утверждаете, что High Availability — это возможность потерять до трети машин, потому что так вам рассказали в CAP. И следом же пишете, что CAP — она вообще не про availability.
Нет, я не утверждаю что это возможность потерять до трети машин. Я говорил про availability в другом контексте.
S>У вас в голове явно есть одновременно два термина availability, с конфликтующими определениями. Availability означает способность выполнять запрошенные операции. То есть если операция отпала по таймауту — это значит, что система non-available. По определению. Поэтому невозможно иметь аvailability без возможности записи/чтения. А у вас получается "прибор работает, но не включается, потому что включается, но не работает".
Вот самое распространенное определение того, что есть availability (из CAP) — "Every request received by a non-failing node in the system must result in a response." (и под response тут имеется ввиду не возврат кода ошибки а ответ о том что все ОК). Это свойство системы, которое заключается в том, что на каждый запрос приходит ответ (если запрос дошел до работающей ноды). Заметь, что свойство никуда не пропадает, если часть машин недоступны. Если мы имеем дело с CP системой (Zookeeper например), то в случае отсутствия кворума мы не сможем ничего сделать (только читать протухшие данные). Если мы имеем дело с AP системой, например с Dinamo — данные будут записаны несмотря ни на что, даже если узел, принявший наш запрос вообще отсоединен от кластера, просто когда он присоединится обратно и мы попробуем прочитать обратно то что было записано — получим конфликт. Это свойство системы не зависит от MTTR вообще никак. Если система является доступной, в нее можно записывать всегда.
Другое определение availability, с которым мне доводилось встречаться (и я думал что ты именно его имеешь ввиду) — это тупо то же самое что и аптайм. Тут мы действительно можем повысить availability поставив дополнительный блок питания, так как вероятность аппаратного сбоя снижается. Но я исхожу из того что а) это само собой разумеется б) в контексте NoSQL availability — свойство системы куда интереснее и полезнее, нежели availability — надежность системы.
При этом одно из второго никак не следует. Можно иметь 100% надежное железо, которое никогда не ломается, все машины кластера могут работать и быть сконфигурированы правильно, при этом система не будет доступной. Вот например Zookeeper кластер — все ноды работают, но часть из них — под высокой нагрузкой, поэтому половина транзакций отваливается. Но при этом с точки зрения надежности и аптайма все хорошо.
S>Она взялась из "минимальной HA" конфигурации. Вы же тут утверждали, что кластер из двух машин не является HA.
S>Ну давайте возьмём кластер из 300 машин. Предположим, MTBF у нас — 1 год, а MTTR = 1000 лет. Какова availability этого кластера при эксплуатации в течение неограниченного времени?
S>Возьмём двухмашинный кластер. Предположим, MTBF у нас по-прежнему 1 год, а MTTR — 5 минут. Какова availability этого кластера?
Это все понятно, я не спорю с тем что время восстановления после сбоя — важно. Но вот подобные рассуждения про профанации, когда ты используешь тот же MTTR для доказательства, это очень странно. Это же среднее значение, т.е. ни о чем вообще. Вот например эксплуатируем кластер из 3х машин. У нас было два сбоя, первый сбой вылечился простой перезагрузкой за одну минуту, второй сбой — аппаратный, пришлось ждать новый сервер неделю. Какой будет MTTR и будет ли он иметь хоть какой-то практический смысл?