| copyright | lastupdated | keywords | subcollection | ||
|---|---|---|---|---|---|
|
2024-11-12 |
transit-gateway |
{{site.data.keyword.attribute-definition-list}}
{: #ha}
High availability{: term} (HA) is a core discipline in an IT infrastructure to keep your apps up and running, even after a partial or full site failure. The main purpose of high availability is to eliminate potential points of failures in an IT infrastructure. {: shortdesc}
{{site.data.keyword.tg_full}} is highly available within any {{site.data.keyword.cloud_notm}} region (for example, Dallas or Washington, DC). However, recovering from disasters that affect an entire region requires planning and preparation.
You are responsible for understanding your configuration, customization, and usage of the service. You are also responsible for being ready to recreate an instance of the service in a new region and restore your data in a new region. {: important}
{{site.data.keyword.cloud_notm}} supports high availability with no single point of failure. The service achieves high availability automatically and transparently by the multi-zone region (MZR) feature provided by {{site.data.keyword.cloud_notm}}.
When you create a transit gateway instance in a particular region, the system automatically enables multiple zones, which do not share a single point of failure.
Transit gateway GRE connections require the gateway owner to configure HA to meet their specific needs. When you configure a GRE connection on a transit gateway, you must specify the availability zone. For a more robust solution, use a Redundant GRE that requires you to configure at least 2 tunnels or configure multiple GRE connections that use different availability zones.
Transit gateway GRE connections require the gateway owner to specifically configure HA for their needs. A GRE connection is a point-to-point connection, has no built-in redundancy, and is a single point of failure. When you configure a GRE connection on a transit gateway, you must specify the availability zone. For a robust HA solution, configure multiple GRE connections that use different availability zones. {: note}
See How IBM Cloud ensures high availability and disaster recovery to learn more about the high availability and disaster recovery standards in {{site.data.keyword.cloud_notm}}. You can also find information about Service Level Agreements.
{: #ha-responsibilities}
To find out more about responsibility ownership for using Transit Gateway between {{site.data.keyword.IBM_notm}} and the customer, see Understanding your responsibilities when using Transit Gateway.
{: #ha-level}
You can achieve high availability on different levels in your IT infrastructure and within different components of your cluster. The level of availability that is right for you depends on several factors, such as your business requirements, the service level agreements (SLAs) that you have with your customers, and the resources that you want to expend.
{: #ha-service}
The level of availability that you set up for your cluster impacts your coverage under the {{site.data.keyword.cloud_notm}} high availability service level agreement terms.
Service level objectives (SLOs) describe the design points that the {{site.data.keyword.cloud_notm}} services are engineered to meet. Transit Gateway is designed to achieve the following availability target.
| Availability target | Target value |
|---|---|
| Availability % | 99.999% |
| {: caption="SLO for Transit Gateway" caption-side="bottom"} |
The SLO is not a warranty and {{site.data.keyword.IBM_notm}} will not issue credits for failure to meet an objective. Refer to the SLAs for commitments and credits that are issued for failure to meet any committed SLAs. For a summary of all SLOs, see {{site.data.keyword.cloud_notm}} service level objectives.
{: #ha-locations}
For more information about service availability within regions and data centers, see Service and infrastructure availability by location.