diff --git a/adoc/SLES4SAP-hana-angi-perfopt-15.adoc b/adoc/SLES4SAP-hana-angi-perfopt-15.adoc index 359953d5..05c468fa 100644 --- a/adoc/SLES4SAP-hana-angi-perfopt-15.adoc +++ b/adoc/SLES4SAP-hana-angi-perfopt-15.adoc @@ -167,7 +167,7 @@ As already explained, the secondary {HANA} database must run with memory resourc restrictions. The HA/DR provider needs to remove these memory restrictions when a takeover occurs. This is why multi SID (also MCOS) must not be used in this scenario. -* *Multi-tier* (_A => B -> C_) and *Multi-target* (_B <= A => C_). +* *Multi-tier* ([A => B] -> C) and *Multi-target* ([B <= A] -> C). + .{HANA} System Replication Scale-Up in the Cluster - performance optimized chain image::SAPHanaSR-ScaleUP-Chain.svg[scaledwidth=100.0%] diff --git a/adoc/SLES4SAP-hana-angi-scaleout-perfopt-15.adoc b/adoc/SLES4SAP-hana-angi-scaleout-perfopt-15.adoc index 97f947ab..9598ecb3 100644 --- a/adoc/SLES4SAP-hana-angi-scaleout-perfopt-15.adoc +++ b/adoc/SLES4SAP-hana-angi-scaleout-perfopt-15.adoc @@ -298,13 +298,13 @@ The third resource agent is *SAPHanaFilesystem*. This RA With the current version of resource agents, {saphana} system replication for scale-out is supported in the following scenarios or use cases: -Performance optimized, single container (A \=> B):: +Performance optimized, single container ([A \=> B]):: In the performance optimized scenario an {saphana} RDBMS on site "A" is synchronizing with an {saphana} RDBMS on a second site "B". As the {saphana} RDBMS on the second site is configured to preload the tables the takeover time is typically very short. See also the requirements section below for details. -Performance optimized, multi-tenancy also named MDC (%A \=> %B):: +Performance optimized, multi-tenancy also named MDC ([%A \=> %B]):: Multi-tenancy is available for all of the supported scenarios and use cases in this document. This scenario is the default installation type for {saphana} 2.0. The setup and configuration from a cluster point of view is the same for @@ -312,14 +312,14 @@ multi-tenancy and single containers. The one caveat is, that the tenants are managed all together by the Linux cluster. See also the requirements section below. -Multi-Tier Replication (A \=> B \-> C):: +Multi-Tier Replication ([A \=> B] \-> C):: A Multi-Tier system replication has an additional target, which must be connected to the secondary (chain topology). This is a special case of the Multi-Target replication. Because of the mandatory chain topology, the RA feature AUTOMATED_REGISTER=true is not possible with pure Multi-Tier replication. See also the requirements section below. -Multi-Target Replication (A \<= B \-> C):: +Multi-Target Replication ([A \<= B] \-> C):: This scenario and setup is described in this document. A Multi-Target system replication has an additional target, which is connected to either the secondary (chain topology) or to the primary (star topology). diff --git a/adoc/SLES4SAP-hana-scaleOut-PerfOpt-12.adoc b/adoc/SLES4SAP-hana-scaleOut-PerfOpt-12.adoc index c6ffc12a..f45da637 100644 --- a/adoc/SLES4SAP-hana-scaleOut-PerfOpt-12.adoc +++ b/adoc/SLES4SAP-hana-scaleOut-PerfOpt-12.adoc @@ -252,7 +252,7 @@ on this node must be limited in using system resources, the table preload must be switched off and a possible takeover needs longer than in the performance optimized use case. -Multi Tier (A > B -> C):: +Multi Tier (A > B > C):: This scenario and setup is described in an other document in the resource library ( {reslibrary} ) for on-premise systems. It can be adopted to Azure too.. A Multi Tier system replication has an additional target, which must be diff --git a/adoc/SLES4SAP-hana-scaleOut-PerfOpt-15.adoc b/adoc/SLES4SAP-hana-scaleOut-PerfOpt-15.adoc index c59ef4d8..9716afe7 100644 --- a/adoc/SLES4SAP-hana-scaleOut-PerfOpt-15.adoc +++ b/adoc/SLES4SAP-hana-scaleOut-PerfOpt-15.adoc @@ -283,14 +283,14 @@ designed as a normal (stateless) clone resource. With the current version of resource agents, {HANA} system replication for scale-out is supported in the following scenarios or use cases: -Performance optimized, single container (A => B):: +Performance optimized, single container ([A \=> B]):: This scenario and setup is described in this document. In the performance optimized scenario an {HANA} RDBMS on site "A" is synchronizing with an {HANA} RDBMS on a second site "B". As the {HANA} RDBMS on the second site is configured to preload the tables the takeover time is typically very short. See also the requirements section below for details. -Performance optimized, multi-tenancy also named MDC (%A => %B):: +Performance optimized, multi-tenancy also named MDC ([%A \=> %B]):: Multi-tenancy is available for all of the supported scenarios and use cases in this document. This scenario is supported since {HANA} 1.0 SPS12, it is the default installation type for {HANA} 2.0. @@ -299,14 +299,14 @@ multi-tenancy and single containers. The one caveat is, that the tenants are managed all together by the Linux cluster. See also the requirements section below. -Multi-Tier Replication (A => B -> C):: +Multi-Tier Replication ([A \=> B] \-> C):: A Multi-Tier system replication has an additional target, which must be connected to the secondary (chain topology). This is a special case of the Multi-Target replication. Because of the mandatory chain topology, the RA feature AUTOMATED_REGISTER=true is not possible with pure Multi-Tier replication. See also the requirements section below. -Multi-Target Replication (A <= B -> C):: +Multi-Target Replication ([A \<= B] \-> C):: A Multi-Target system replication has an additional target, which is connected to either the secondary (chain topology) or to the primary (star topology). Multi-Target replication is possible since {HANA} 2.0 SPS04. diff --git a/adoc/SLES4SAP-hana-scaleout-multitarget-perfopt-15.adoc b/adoc/SLES4SAP-hana-scaleout-multitarget-perfopt-15.adoc index 18ac3764..b5adc806 100644 --- a/adoc/SLES4SAP-hana-scaleout-multitarget-perfopt-15.adoc +++ b/adoc/SLES4SAP-hana-scaleout-multitarget-perfopt-15.adoc @@ -291,13 +291,13 @@ designed as a normal (stateless) clone resource. With the current version of resource agents, {saphana} system replication for scale-out is supported in the following scenarios or use cases: -Performance optimized, single container (A \=> B):: +Performance optimized, single container ([A \=> B]):: In the performance optimized scenario an {saphana} RDBMS on site "A" is synchronizing with an {saphana} RDBMS on a second site "B". As the {saphana} RDBMS on the second site is configured to preload the tables the takeover time is typically very short. See also the requirements section below for details. -Performance optimized, multi-tenancy also named MDC (%A \=> %B):: +Performance optimized, multi-tenancy also named MDC ([%A \=> %B]):: Multi-tenancy is available for all of the supported scenarios and use cases in this document. This scenario is the default installation type for {saphana} 2.0. The setup and configuration from a cluster point of view is the same for @@ -305,15 +305,16 @@ multi-tenancy and single containers. The one caveat is, that the tenants are managed all together by the Linux cluster. See also the requirements section below. -Multi-Tier Replication (A \=> B \-> C):: +Multi-Tier Replication ([A \=> B] \-> C):: A Multi-Tier system replication has an additional target, which must be connected to the secondary (chain topology). This is a special case of the Multi-Target replication. Because of the mandatory chain topology, the RA feature AUTOMATED_REGISTER=true is not possible with pure Multi-Tier replication. See also the requirements section below. -Multi-Target Replication (A \<= B \-> C):: -This scenario and setup is described in this document. A Multi-Target system replication has an additional target, which is connected to +Multi-Target Replication ([A \<= B] \-> C):: +This scenario and setup is described in this document. A Multi-Target system +replication has an additional target, which is connected to either the secondary (chain topology) or to the primary (star topology). Multi-Target replication is possible since {saphana} 2.0 SPS04. See also the requirements section below. diff --git a/adoc/SLES4SAP-hana-sr-guide-PerfOpt-15.adoc b/adoc/SLES4SAP-hana-sr-guide-PerfOpt-15.adoc index f3cdded1..b2cc3bab 100644 --- a/adoc/SLES4SAP-hana-sr-guide-PerfOpt-15.adoc +++ b/adoc/SLES4SAP-hana-sr-guide-PerfOpt-15.adoc @@ -189,7 +189,7 @@ As already explained, the secondary {HANA} database must run with memory resourc restrictions. The HA/DR provider needs to remove these memory restrictions when a takeover occurs. This is why multi SID (also MCOS) must not be used in this scenario. -* *Multi-tier* (_A => B -> C_) and *Multi-target* (_B <= A => C_). +* *Multi-tier* ([A => B] -> C) and *Multi-target* ([B <= A] -> C). + .{HANA} System Replication Scale-Up in the Cluster - performance optimized chain image::SAPHanaSR-ScaleUP-Chain.svg[scaledwidth=100.0%] diff --git a/adoc/SLES4SAP-hana-sr-guide-costopt-15.adoc b/adoc/SLES4SAP-hana-sr-guide-costopt-15.adoc index e952a94b..7e837835 100644 --- a/adoc/SLES4SAP-hana-sr-guide-costopt-15.adoc +++ b/adoc/SLES4SAP-hana-sr-guide-costopt-15.adoc @@ -175,7 +175,7 @@ As already explained, the secondary {HANA} database must run with memory resourc restrictions. The HA/DR provider needs to remove these memory restrictions when a takeover occurs. This is why multi SID (also MCOS) must not be used in this scenario. -* *Multi-tier* (_A => B -> C_) and *Multi-target* (_B <= A => C_). +* *Multi-tier* ([A => B] -> C) and *Multi-target* ([B <= A] -> C). + .{HANA} System Replication Scale-Up in the Cluster - performance optimized chain image::SAPHanaSR-ScaleUP-Chain.svg[scaledwidth=100.0%]