Комментарии 15
>При разрыве связи все печальнее. Узел не может позволить себе умереть, потому что возможно только он и обеспечивает работоспособность (без связи с другими узлами невозможно понять, есть ли еще кто-то живой).
Печальней ли?
linux-ha.org/wiki/Cluster_Concepts#Determination_of_Quorum
Печальней ли?
linux-ha.org/wiki/Cluster_Concepts#Determination_of_Quorum
Конечно, печальнее.
Цитирую статью по вашей ссылке: «Nevertheless, no quorum algorithm can provide an absolute guarantee of this property in the presence of arbitrary failures. Different quorum implementations provide different degrees of certainty for any given configuration and set of expected failures.»
Именно про простейший вариант кворума написано в «лирическом отступлении». Читайте внимательнее.
Цитирую статью по вашей ссылке: «Nevertheless, no quorum algorithm can provide an absolute guarantee of this property in the presence of arbitrary failures. Different quorum implementations provide different degrees of certainty for any given configuration and set of expected failures.»
Именно про простейший вариант кворума написано в «лирическом отступлении». Читайте внимательнее.
Эх, всё равно не до конца понятно, давайте по полочкам:
CP —
AP —
CA — ?
CP —
A и B, видя, что потеряли связь друг с другом, перестают обрабатывать запросы. В этом случае согласованность не нарушится, но будет потеряна availability.
AP —
Когда связь между A и B восстановится, при синхронизации всплывет конфликт — удалить R или оставить модифицированную версию? Тут можно выкручиваться разными стратегиями разрешения конфликтов, но consistency мы уже потеряли.
CA — ?
CA означает, что система неустойчива к сплитам. Соответственно, пока сплита нет, мы имеем СА. Как только произошел сплит — выбирайте, С или А. В первом случае это может быть DOS (или работа только на чтение, например), во втором -несогласованность данных.
Тогда получается либо если нету P то нету и CA — либо просто C, либо просто A, a если есть P — то CP либо CA. так?
Ошибся в последнем сообщении: без P — A или C, с P — CP или AP.
CA как таковой не существует? Потому как «система неустойчива к сплитам» не очень вяжется с «пока сплита нет» — если неустойчива к сплитам, оценивать нужно по худшей ситуации, т.е. сплит есть.
CA как таковой не существует? Потому как «система неустойчива к сплитам» не очень вяжется с «пока сплита нет» — если неустойчива к сплитам, оценивать нужно по худшей ситуации, т.е. сплит есть.
Очень даже вяжется.
«Система неустойчива к сплитам» как раз и означает, что как только сплит — мы ничего не гарантируем. Все в силе только «пока сплита нет».
Представьте, вам предлагают построить дом, в котором ничего не сделано для защиты от ураганов. Пока урагана нет — все хорошо. Как только ураган — вам ничего не гарантируют.
Купите вы такой дом? — Почему бы и нет, если вы живете не в Канзасе и про ураганы разве что читали в «Волшебнике Изумрудного города».
Или вы станете «оценивать по худшей ситуации» и жить в бункере с защитой от цунами, взрывов водородной бомбы и пятью линиями вооруженной охраны, испытывая все связанные с таким непростым местом жительства неудобства?
«Система неустойчива к сплитам» как раз и означает, что как только сплит — мы ничего не гарантируем. Все в силе только «пока сплита нет».
Представьте, вам предлагают построить дом, в котором ничего не сделано для защиты от ураганов. Пока урагана нет — все хорошо. Как только ураган — вам ничего не гарантируют.
Купите вы такой дом? — Почему бы и нет, если вы живете не в Канзасе и про ураганы разве что читали в «Волшебнике Изумрудного города».
Или вы станете «оценивать по худшей ситуации» и жить в бункере с защитой от цунами, взрывов водородной бомбы и пятью линиями вооруженной охраны, испытывая все связанные с таким непростым местом жительства неудобства?
Не «брейнсплит», а «сплитбрейн». Вечная проблема для любых кластерных систем.
Дмитрий, спасибо большое за подробное разъяснение. К сожалению, статью увидел только сегодня, поэтому и коммент пишу только сейчас.
В целом, я с Вами абсолютно согласен, действительно, теорема построена и доказана для модели. Я в своем топике, в комментариях, к сожалению ушел от темы теоремы и стал рассуждать о возможности построения CA системы в «реальном мире». Хотя, впрочем, теоретическая часть теоремы мне не очень интересна, мне важно ее применение на практике.
Но все же напишу пару слов о некоторых ваших высказываниях, которые меня немного покоробили:
1. Чисто формально в теореме Avalability — это способность давать ответ не упавших компонент. Т.е. пример о невозможности построения системы со 100% avalability в терминах теоремы не совсем корректен. Мне все таки кажется создать систему полностью согласованной или полностью доступной в терминах теоремы все же можно, в отличие от системы без 100% потерь связи. Но Вы совершенно правы, в теореме мы имеем дело с моделью, поэтому об этом говорить можно.
2. Ваш пример CA системы, где придется что-то чинить руками в случае маловероятного сплита, мне кажется не совсем хорошим, так как во время починки, ваша система уже не будет A, соответственно, и не будет CA.
3. Вы привели очень хороший пример с домом. И я как практик с вами очень даже соглашусь. Но как теоретик, я призадумаюсь. Ведь, если уж мы говорим о теореме с моделью, то как-то называть систему сначала CA, а потом, когда что-то произошло называть CP или AP, не кажется мне очень логичным. Все таки в теореме мы говорим о постоянном свойстве системы, с обозначенными свойствами модели.
Еще раз повторю, что с мыслью проходящей сквозь весь Ваш топик я абсолютно согласен. Теорема — эта модель и, что ее нельзя получить в реальном мире, ее это мало волнует. Однако переходя все же из теоремы в реальный мир, я вижу очень полезное утверждение, которое напрямую следует из этой теоремы. Так как в реальном мире устойчивость к сплиту достичь на 100% невозможно (но вы совершенно верно, невозможно пока), то и построить систему на 100% удовлетворяющую CA невозможно. Ну или можно еще сформулировать как это Вы сделали, т.е. можно, но до первой потери сообщения.
Нда, немного противоречивый комментарий получился. Ну уж какой есть :)
В целом, я с Вами абсолютно согласен, действительно, теорема построена и доказана для модели. Я в своем топике, в комментариях, к сожалению ушел от темы теоремы и стал рассуждать о возможности построения CA системы в «реальном мире». Хотя, впрочем, теоретическая часть теоремы мне не очень интересна, мне важно ее применение на практике.
Но все же напишу пару слов о некоторых ваших высказываниях, которые меня немного покоробили:
1. Чисто формально в теореме Avalability — это способность давать ответ не упавших компонент. Т.е. пример о невозможности построения системы со 100% avalability в терминах теоремы не совсем корректен. Мне все таки кажется создать систему полностью согласованной или полностью доступной в терминах теоремы все же можно, в отличие от системы без 100% потерь связи. Но Вы совершенно правы, в теореме мы имеем дело с моделью, поэтому об этом говорить можно.
2. Ваш пример CA системы, где придется что-то чинить руками в случае маловероятного сплита, мне кажется не совсем хорошим, так как во время починки, ваша система уже не будет A, соответственно, и не будет CA.
3. Вы привели очень хороший пример с домом. И я как практик с вами очень даже соглашусь. Но как теоретик, я призадумаюсь. Ведь, если уж мы говорим о теореме с моделью, то как-то называть систему сначала CA, а потом, когда что-то произошло называть CP или AP, не кажется мне очень логичным. Все таки в теореме мы говорим о постоянном свойстве системы, с обозначенными свойствами модели.
Еще раз повторю, что с мыслью проходящей сквозь весь Ваш топик я абсолютно согласен. Теорема — эта модель и, что ее нельзя получить в реальном мире, ее это мало волнует. Однако переходя все же из теоремы в реальный мир, я вижу очень полезное утверждение, которое напрямую следует из этой теоремы. Так как в реальном мире устойчивость к сплиту достичь на 100% невозможно (но вы совершенно верно, невозможно пока), то и построить систему на 100% удовлетворяющую CA невозможно. Ну или можно еще сформулировать как это Вы сделали, т.е. можно, но до первой потери сообщения.
Нда, немного противоречивый комментарий получился. Ну уж какой есть :)
Господа, ощущение что нам нужен еще один топик для продолжения обсуждения, или даже два. Обзор стратегий разрешения конфликтов для обеспечения, собственно, Eventual Consistency, и обзор борьбы со brainsplit-ом (кворумы и прочее, какие техники применяются в распределенныхт системах, например, в Oracle Coherence).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разъяснение по CAP-теореме