@koliama а можно чуть подробней описать что именно подразумевается под "Если на нодах неактивирован один из блочных протоколов" ?

гм.. ну если совсем подробно, то например если нет svm с fc или iscsi, не сказано iscsi enable. насчет nvme и fcoe не знаю, не тестировал. не обязательно что-то выдавать с созданных svm, главное чтобы они были созданы и активированы протоколы. как-то так..

Это эксперимент уровня: мы вытащили два диска из RAID10 и у нас все развалилось, мы вытащили из второго такого же массива и там не развалилось, потому что нам повезло и попались диски из разных пар.

угу.. вообще это в доке от вендора описано.. но тебе виднее видимо)

а написал я это к тому что сталкивался с ситуацией, когда при переходе от одной версии онтап к другой поведение двухнодового кластера менялось и кластер разваливался независимо от того были ли на нем svm с блочными протоколами или нет.. по моему это было в 9.0-9.1, потом алгоритм обработки такого сбоя снова поменялся..

Что именно? То что san lif переезжает, а NAS - нет?

причем тут lif вообще?)

и с чего вдруг san lif куда-то переезжает?) ты вчера хорошо отдохнул что-ли?)

Сан лиф не переезжает же

да, наоборт. подумла одно, написал другое.

для особо недоверчивых))

Выдержка из доки
What happens in a two-node cluster if the cluster interconnect fails?
Answer: The cluster interconnect is a critical component of the cluster architecture and is architected for resilience and reliability. Requirements for supported NICs and ports, cluster inter-connect switches and switch configuration must be strictly adhered to when ordering and configuring a cluster to ensure no single point of failure in the infrastructure
As previously stated, in a 2-node cluster, there is no epsilon – cluster HA must be enabled to allow either node to takeover for the other and maintain quorum if only one of the nodes is up. Takeover is required to maintain quorum.
CLAM (Cluster Liveliness Availability Monitor) introduced with SAN support in clustered Data ONTAP 8.1, monitors heartbeats over the cluster interconnect, regardless of whether SAN protocols are licensed and configured.
If heartbeats are dropped because of cluster interconnect failure (switch failure, cables cut etc) or one node becomes isolated (all its cluster ports or LIFs fail), both nodes drop out of quorum. CLAM detects the out of quorum condition and logs appropriate messages . The timeout period for lost interconnect heartbeats is around 22.5 seconds. In a cluster with 2 cluster interconnect LIFs, this would only occur after dual or more failures. A one-cable two-node switchless cluster (switchless FAS2220 or FAS2240 with clustered Data ONTAP 8.2 only) however has a single point of failure which should be carefully positioned if proposing this configuration to customers. It does not meet the NDO Minimum Configuration. Regardless of the number of interconnects, there are two possibilities for what occurs next.
1. If at least one SAN object is configured (LUN, portset, etc), then CLAM induces a takeover by one of the nodes after the cluster interconnect timeout. The taking over node must be otherwise healthy and capable of performing the takeover. The node which took over is now in a "quorum of one" as for any other takeover, and full data services, NAS and SAN, are resumed on this node. After fixing the issue with the cluster interconnect, the administrator can perform a giveback to resume normal two-node operation.
2. If the cluster has NO SAN objects, then no automatic takeover occurs, both nodes remain out of quorum and neither will serve data. Manual intervention will be required to either restore the cluster interconnect or perform a takeover.

а вот у многонодовых кластеров почему-то все печальнее. если одна нода из ha пары в, например, четырехнодовом кластере изолировалась, то тейковера не происходит и данные с этой ноды будут недоступны. при этом остальные ноды в кластере будут работать в штатном режиме

Коля, реально же фигней занимаешься.
есть элемент инфраструктуры, который защищен от SPOF. Ты рассматриваешь ситуацию, когда пропало N+1 элементов. Хотя архитектура предусматривает работу только при потере N элементов. То есть, ситуации, когда возможна работа при потере N+1 элементов — это приятный бонус.

Артур, я думаю что не все знают о таких "фичах" нетапа. и надеюсь что моя информация будет кому-то полезна и позволит избежать потери доступа к данным в ситуации когда ее можно избежать. что касаемо SPOF, то я по этому вопросу дискутировал с @Roman_Roifman еще в 14-ом году и он меня не убедил. если у меня есть кластер с кворумом то почему нельзя доработать механизм проверки целостности таким образом чтобы избежать не только потери данных но и потери доступа к оным?

тем более что примеров таких решений на рынке не так уж мало

*hitachi заплакал*

А вот это вы зря. Если интересно, то почитайте про технологию HDS Global Active Device.

я в курсе потому и *hitachi заплакал*

Вы сейчас тоже какой-то фигней занимаетесь, приплетая сюда решения уровня метрокластера.