-
Distributing traffic across cluster nodes
-
Managing the Citrix ADC cluster
-
Node groups for spotted and partially striped configurations
-
Behavior of node groups
-
Configuring node groups for spotted and partially striped configurations
-
-
Removing a node from a cluster deployed using cluster link aggregation
-
Monitoring command propagation failures in a cluster deployment
-
Monitor Static Route (MSR) support for inactive nodes in a spotted cluster configuration
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
Behavior of node groups
Due to the interoperability of node groups with different Citrix ADC features and entities, there are some behavioral aspects to be noted. Nodes in a node group can also be backed up. Read on for more information.
General behavior of a cluster node group
- A node group that has entities bound to it cannot be removed.
- A cluster node that belongs to a node group with entities bound to it, cannot be removed.
- A cluster instance that has node groups with entities bound to it, cannot be removed.
-
You cannot add an entity that has a dependency on another entity. It must not be a part of the node group. If you must do so, first remove the dependency. Then, add both the entities to the node group and reassociate the entities.
Examples:
- Assume you have a virtual server, VS1, whose backup is virtual server VS2. To add VS1 to a node group, first make sure that VS2 is removed as the backup server of VS1. Then, bind each server individually to the node group, and then configure VS2 as the backup for VS1.
- Assume you have a content switching virtual server, CSVS1, whose target load balancing virtual server is LBVS1. To add CSVS1 to a node group, first remove LBVS1 as the target. Then, bind each server individually to the node group, and then configure LBVS1 as the target.
- Assume you have a load balancing virtual server, LBVS1, that has a policy which invokes another load balancing virtual server, LBVS2. To add either one of the virtual servers, first remove the association. Then, bind each server individually to the node group, and then reassociate the virtual servers.
- You cannot bind an entity to a node group. It has no nodes and that has the strict option enabled. Therefore, you cannot unbind the last node of a node group that has entities bound to it and that has the strict option enabled.
- The strict option cannot be modified for a node group that has no nodes but has entities bound to it.
Backing up nodes in a node group
By default, a node group is designed to provide back up nodes for members of a node group. If a node group member goes down, a cluster node that is not a member of the node group dynamically replaces the failed node. This node is called the replacement node.
Note
For a single-member node group, a backup node is automatically preselected when an entity is bound to the node group.
When the original member of the node group comes up, the replacement node, by default, is replaced by the original member node.
From NetScaler 10.5 Build 50.10 onwards, however, the Citrix ADC allows you to change this replacement behavior. When you enable the sticky option, the replacement node is retained even after the original member node comes up. The original node takes over only when the replacement node goes down.
You can also disable the backup functionality. To do it, you must enable the strict option. In this scenario, when a node group member goes down, no other cluster node is picked up as a backup node. The original node continues being part of the node group when it comes up. This option ensures that entities bound to a node group are active only on node group members.
Note
The strict and sticky option can be set only when creating a node group.
Share
Share
This Preview product documentation is Cloud Software Group Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Cloud Software Group Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Cloud Software Group product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.