Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

to fix issue #444 #445

Merged
merged 3 commits into from
Jul 30, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion adoc/SLES4SAP-hana-angi-perfopt-15.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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%]
Expand Down
8 changes: 4 additions & 4 deletions adoc/SLES4SAP-hana-angi-scaleout-perfopt-15.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -298,28 +298,28 @@ 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
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).
Expand Down
2 changes: 1 addition & 1 deletion adoc/SLES4SAP-hana-scaleOut-PerfOpt-12.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
8 changes: 4 additions & 4 deletions adoc/SLES4SAP-hana-scaleOut-PerfOpt-15.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand All @@ -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.
Expand Down
11 changes: 6 additions & 5 deletions adoc/SLES4SAP-hana-scaleout-multitarget-perfopt-15.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -291,29 +291,30 @@ 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
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.
Expand Down
2 changes: 1 addition & 1 deletion adoc/SLES4SAP-hana-sr-guide-PerfOpt-15.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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%]
Expand Down
2 changes: 1 addition & 1 deletion adoc/SLES4SAP-hana-sr-guide-costopt-15.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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%]
Expand Down