vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Highly available system for SAP NetWeaver on IBM Cloud VPC 

In a highly available (HA) system, every instance can run on a separate IBM Cloud virtual server instance. The cluster HA configuration for the SAP application server consists of two virtual server instances, each of them located in the same zone within the region by using placement groups. Placement groups assure that both cluster resources and cloud resources are also located in different compute nodes as specified in the following placement groups section.

Zoom

![Figure 1. SAP HA for SAP applications cluster nodes PAS (Active) and AAS (Active)](https://cloud.ibm.com/docs-content/v1/content/f89cc64b006ca59b35404693959c83d5747fee3e/sap/images/sap-ha-vpc-single-zone.png)

Figure 1. SAP HA for SAP applications cluster nodes PAS (Active) and AAS (Active)



 Placement groups on IBM Cloud VPC for SAP HA architecture 

Placement groups (PG) for VPC have two different anti-affinity strategies for high availability. By using placement strategies, you minimize the chance of service disruption with virtual server instances that are placed on different hosts or into an infrastructure with separate power and network supplies.

The design of placement groups for IBM Cloud virtual servers solves this issue. Placement groups give you a measure of control over the host on which a new public virtual server is placed. With this release, a “spread” rule is implemented, which means that virtual servers within a placement group are all spread onto different hosts. You can build a highly available application within a data center and know that your virtual servers are isolated from each other.

Placement groups with the “spread” rule are available to create in select IBM Cloud data centers. After a "spread" rule is created, you can provision a virtual server into that group and ensure that it won't be on the same host as any of your other virtual servers. The best part? There’s absolutely no charge for using this feature.

You can create your placement group, then assign up to four new virtual server instances. With the "spread" rule, each of your virtual servers are provisioned on different physical hosts.
Why does no Ingress subdomain exist after cluster creation? 

Virtual Private Cloud

Classic infrastructure

 What’s happening 

You create a cluster and run ibmcloud oc cluster get --cluster <cluster> to check its status. The cluster State is normal, but the Ingress Subdomain and Ingress Secret are not available.

 Why it’s happening 

Even if the cluster is in a normal state, the Ingress subdomain and secret might still be in progress. The Ingress subdomain and secret creation might take more than 15 minutes to complete:

Classic clusters:



1. When worker nodes are fully deployed and ready on the VLANs, a portable public and a portable private subnet for the VLANs are ordered.
2. After the portable subnet orders are successfully fulfilled, the ibm-cloud-provider-vlan-ip-config config map is updated with the portable public and portable private IP addresses.
3. When the ibm-cloud-provider-vlan-ip-config config map is updated, the Ingress controller is triggered for creation.
4. A load balancer service that exposes the Ingress controller is created and assigned an IP address.
5. The load balancer IP address is used to register the Ingress subdomain in Akamai. Akamai might have latency during the registration process.



VPC clusters:



1. When you create a VPC cluster, one public and one private VPC load balancer are automatically created outside of your cluster in your VPC.
2. One public Ingress controller per zone is triggered for creation.
3. A load balancer service that exposes the Ingress controller is created and assigned a hostname.
4. The load balancer hostname is used to register the Ingress subdomain in Akamai. Akamai might have latency during the registration process.



Creating a cluster after deleting a cluster the same or similar name?
* Reduced business downtime and improved RTO KPIs by moving the SAP HANA main data column store to Intel Optane DC Persistent Memory, with all data immediately accessible after planned or unplanned maintenance windows.







 Intel Virtual Servers on VPC Infrastructure 

IBM® Virtual Servers are virtual machine servers with extensive customization capabilities.

The servers run on a hypervisor that is managed by IBM Cloud, providing you flexible compute by using a scalable infrastructure (available in multi-tenant or dedicated single-tenant).

These servers are managed by the account holder, either you, your customer, or your services partner, depending on your business operations.

These servers are provisioned with your choice of operating system (OS) image that is installed to Virtual Servers.

IBM Cloud VPC Infrastructure is available for:



* Intel Virtual Servers, based on the latest hardware designs with large improvements across networking performance (up to 80 Gbps), provision times (5x faster), and a flexible selection of extra features



For more information about Virtual Servers on VPC Infrastructure, see [What is IBM Cloud VPC?](https://www.ibm.com/cloud/learn/vpc) and [IBM Cloud Virtual Server for VPC](https://www.ibm.com/cloud/virtual-servers) on ibm.com and [IBM Cloud Intel Virtual Servers on VPC Infrastructure](https://cloud.ibm.com/docs/vpc?topic=vpc-about-advanced-virtual-servers) on IBM Cloud Docs.





 Intel Bare Metal servers on VPC Infrastructure 

IBM Cloud® Bare Metal Servers are physical servers with numerous customization capabilities.

The servers are dedicated for your use, or your customer's, and not shared in any part, including server resources, with other IBM Cloud customers.

These servers are managed by the account holder, either you, your customer, or your services partner, depending on your business operations.

These servers are provisioned with your choice of operating system (OS) image that is directly installed to bare metal.

Because customization is controlled on bare metal servers, fast provisioning times of in the range 1 - 4 hours are obtainable with worldwide availability.
A DNS service resolves the route subdomain to the VPC load balancer hostname that is assigned to the services for the Ingress controller. In VPC clusters, your Ingress controller services' external IP addresses are floating, and are kept behind a VPC-assigned hostname.
3. The VPC load balancer resolves the VPC hostname to an available external IP address of a Ingress controller service that was reported as healthy. The VPC load balancer continuously checks the external IP addresses of the services that expose the Ingress controller in each zone in your cluster.
4. Based on the resolved IP address, the VPC load balancer sends the request to a Ingress controller service.
5. The Ingress controller forwards the request to the private IP address of the app pod over the private network. The source IP address of the request packet is changed to the IP address of the worker node where the Ingress controller pod runs. Each Ingress controller sends requests to the app instances in its own zone and to app instances in other zones. Additionally, if multiple app instances are deployed in one zone, the Ingress controller alternates requests between app pods.
6. When the app returns a response packet, it uses the IP address of the worker node where the Ingress controller that forwarded the client request exists. The Ingress controller then sends the response packet through the VPC load balancer to the client.







 Traffic flow in a multizone VPC cluster with a private cloud service endpoint only 

When you create a multizone VPC cluster with the private cloud service endpoint only, a private Ingress controller is created by default. The Ingress controller assigns privately accessible routes for your apps and listens on the private host network interface. Only clients that are connected to your private VPC network can access apps that are exposed by a private route.

The following diagram shows how a Ingress controller directs network traffic from private networks to an app in a multizone, VPC cluster.

Zoom

!
IBM Cloud operations might change the number and value of your assigned private IP addresses over time, based on maintenance and scaling activities. The back-end virtual server instances that host your application must run in the same region and under the same VPC.

Use the assigned ALB FQDN to send traffic to the private application load balancer to avoid connectivity problems to your applications during system maintenance or scaling down activities.

Each ALB sends traffic to the cluster node where the application (ASCS, ERS, HANA DB) is running. During the cluster failover, the ALB redirects all the traffic to the new node where the resources are up and running.

DNSaaS (DNS as a Service) is the management IBM Cloud VPC DNS service of HA and FQDN (IPs) mechanism.

The ALB has a default of 50 seconds for client and server timeout, so after 50 seconds of inactivity, the connections close. To support SAP connections through ALB and not lose connection after 50 seconds, you need to request a change this value to a minimum of 300 seconds (client-side idle connection = minimum 300s and server-side idle connection = minimum 300s). To request this change, open a support ticket. This is an account-wide change that affects all of the ALBs in your account. For more information, see [Connection timeouts](https://cloud.ibm.com/docs/docs/vpc?topic=vpc-advanced-traffic-managementconnection-timeouts).





 DNS Services with VPC 

[IBM Cloud DNS Services](https://cloud.ibm.com/docs/vpc?topic=vpc-about-dns-srvcs) provides private DNS to VPC users. Private DNS zones are resolvable only on IBM Cloud, and only from explicitly [permitted networks](https://cloud.ibm.com/docs/dns-svcs?topic=dns-svcs-dns-conceptspermitted-networks) in an account. To get started, create a DNS Services instance using the IBM Cloud console.

DNS Services allow you to:



* Create private DNS zones that are collections for holding domain names.
ux2d-200x5600 200 5,600 215,570 



For more information, see [SAP Note 2927211 - SAP Applications on IBM Cloud Virtual Private Cloud (VPC) Infrastructure environment](https://launchpad.support.sap.com//notes/2927211).





 Understanding Virtual Server profile names 

With IBM Cloud® Virtual Servers for Virtual Private Cloud, the profile families that are certified for SAP are: Balanced, Memory Optimized, Very High and Ultra High Memory.



* Balanced family profiles, provide a good mix of performance and scalability for more common workloads.
* All the Memory family profiles provide for memory intensive workloads, such as intensive database applications and in-memory analytics workloads, and are especially designed for SAP HANA workloads.



For more information, see [Intel Virtual Server for VPC Infrastructure documentation](https://cloud.ibm.com/docs/vpc?topic=vpc-profiles).

The first letter of the profile name indicates the profile family mentioned above:



Table 2. IBM Cloud® Virtual Servers for Virtual Private Cloud Profile Families

 First letter Characteristics of the related profile family 

 c Compute family, CPU to Memory ratio 1:2 
 b Balanced family, CPU to Memory ratio 1:4 
 m Memory Optimized family, higher CPU to Memory ratio 1:8 
 v Very High Memory Optimized family, very high CPU to Memory ratio 1:14 
 u Ultra High Memory Optimized family, ultra high CPU to Memory ratio 1:28 



For SAP HANA, only the memory profile families are used, for NetWeaver also the balanced family may be considered. The Virtual Server profile names are contextual and sequential. See here one example:



Table 3. Profile naming for SAP HANA

 Profile name Naming convention component What it means 

 mx2-16x128 m Memory Optimized family 
 x Intel x86_64 CPU Architecture 
 2 The generation for the underlying hardware 
 — spacer 
 16 16 vCPU 
 x spacer 
 128 128 GiB RAM 







 Profiles available on Hourly Consumption Billing 

All IBM Cloud Virtual Servers for VPC are available with Hourly Consumption Billing, which includes Suspend Discounts and Sustained Usage Discounts.
[Adding virtual private endpoint gateways](https://cloud.ibm.com/docs-content/v1/content/6a28e4ae2660b609a18e90e1239ed772f80373d6/transit-gateway/includes/solution-tutorials/includes/solution-tutorials/images/vpc-transit/vpc-transit-vpe.svg)

Adding virtual private endpoint gateways



1. Create a IBM Cloud Databases for Redis instance and VPEs for the transit and each of the spoke VPCs, by applying the vpe_transit_tf and vpe_spokes_tf layers:

./apply.sh vpe_transit_tf vpe_spokes_tf
2. There is a set of vpe and vpedns tests that are available in the pytest script. The vpedns test will verify that the DNS name of a Databases for Redis instance is within the private CIDR block of the enclosing VPC. The vpe test will execute a redli command to access the Databases for Redis instance remotely. Test vpe and vpedns from spoke 0 zone 1:

pytest -m 'vpe or vpedns' -k spoke0-z1

Notice the failing vpedns tests like this one:
IBM Cloud Direct Link overview 

IBM Cloud® Direct Link offerings provide connectivity from an external source into a customer IBM Cloud private network. Direct Link can be viewed as an alternative to a site-to-site VPN solution, which is designed for customers that need more consistent, higher-throughput connectivity between a remote network and their IBM Cloud environments.

The IBM Cloud Direct Link service is a routed OSI Layer-3 service. It offers a direct connection to the IBM Cloud private network backbone. Currently, two types of Direct Link connections are available:



* Direct Link Dedicated - Offers a single-tenant, fiber-based cross-connect into the IBM Cloud network.
* Direct Link Connect - Offers private access through various service providers into the IBM Cloud network and to any other clouds.



For more information, see [About IBM Cloud Direct Link (2.0)](https://cloud.ibm.com/docs/dl?topic=dl-dl-about).



 Considerations with roll-your-own VMware solution in VPC 

When you use the VMware® virtual machines (VMs) on VPC subnets architecture, your VMs are attached to VPC subnets and the routing behaves in the same way as with VPC Virtual Servers. The VPC subnets are provisioned from the zone prefix, and when the VPC is attached to a Direct Link, the routing works between on-premises without any required changes. If you are using IANA-registered IP addresses in your VPC, see [Routing considerations for IANA-registered IP assignments](https://cloud.ibm.com/docs/vpc?topic=vpc-interconnectivityrouting-considerations-iana).

Zoom

![Direct Link with VMware on VPC](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/vpc-ryo-diagrams-dl-sub-arch.svg)

Figure 1. Direct Link with VMware on VPC
RackWare Management Module (RMM) solution simplifies the overall migration process of moving the operating system, applications, and data from one bare metal server to another in the IBM Cloud® classic environment. The migration can occur either over the public or private interface of the compute resource. The only requirement is that RMM must be able to access both source and target server over SSH.

Virtual Servers for Classic Building infrastructure



* 45 minutes
* 2022-11-23



[Classic bare metal to bare metal or virtual server on VPC using a private network](https://cloud.ibm.com/docs/cloud-infrastructure?topic=cloud-infrastructure-pv-migration-private-network)Classic bare metal to bare metal or virtual server on VPC using a private network

This is the process of migrating from a classic physical bare metal server to a bare metal or virtual server instance on VPC environment. The RackWare Management Module (RMM) solution simplifies the overall migration process of moving the operating system, applications, and data from the classic bare metal to bare metal or virtual server instance on an IBM Cloud® VPC.

Virtual Servers for Classic Virtual Private Cloud (VPC)

+2

Transit Gateway,Building infrastructure



* 25 minutes
* 2022-12-16



[Classic VMware VM to IBM Cloud VPC migration with RMM ](https://cloud.ibm.com/docs/cloud-infrastructure?topic=cloud-infrastructure-migrating-images-vmware-vpc-classic)Classic VMware VM to IBM Cloud VPC migration with RMM

The RackWare Management Module (RMM) migration solution provides a seamless virtual-to-virtual replatforming for VMware virtual machine (VM) to IBM Cloud® virtual server instance migration. It allows the adoption of existing capabilities of IBM Cloud. Its intuitive GUI permits moving the OS, application, and data from VMware ESXi in IBM Cloud classic to IBM Cloud VPC virtual server instances.

Virtual Private Cloud (VPC) Virtual Servers for Classic

+1

Building infrastructure



* 60 minutes
* 2022-04-28
This tutorial walks you through the steps of creating infrastructure for a IBM Cloud® Virtual Private Cloud (VPC) based microservice architecture. In this architecture, VPCs are connected to each other using the IBM Cloud® Transit Gateway. A set of shared microservices is accessed through host names registered in the IBM Cloud® DNS Services. Each VPC is managed by a separate team isolated by IBM Cloud® Identity and Access Management. Optionally a IBM Cloud® Load Balancer can be used to scale out the shared microservice.

![solution tutorial icon](https://cloud.ibm.com/media/docs/images/homepage/solution-tutorial.svg) [Text analysis with Code Engine](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-text-analysis-code-engine)Text analysis with Code Engine Solution tutorial

In this tutorial, you will learn about IBM Cloud® Code Engine by deploying a text analysis with Natural Language Understanding application. You will create a Code Engine project, select the project and deploy Code Engine entities - applications and jobs - to the project. You will learn how to bind IBM Cloud services to your Code Engine entities. You will also understand the auto-scaling capability of Code Engine where instances are scaled up or down (to zero) based on incoming workload.

![solution tutorial icon](https://cloud.ibm.com/media/docs/images/homepage/solution-tutorial.svg) [Use a VPC/VPN gateway for secure and private on-premises access to cloud resources](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-site2site-vpn)Use a VPC/VPN gateway for secure and private on-premises access to cloud resources Solution tutorial

This tutorial provides the automation to create resources that demonstrate Virtual Private Network (VPN) connectivity between on-premises servers and cloud resources like IBM Cloud® Virtual Private Cloud Virtual Service Instances (VSIs) and IBM Cloud data services. DNS resolution to cloud resources is also configured.
This is the scenario illustrated in [this tutorial](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-configuring-IPSEC-VPNconfiguring-IPSEC-VPN).

There are two sub-patterns depending on the potential for address space overlap.



* No Address Overlapping: when there’s no address overlap of address ranges and risk of conflict between the networks.
* Partial Address Overlapping: when the client and IBM Cloud IP address spaces use the same address range and there is potential for overlap and conflict. In this case client subnet addresses are chosen which don’t overlap in IBM Cloud private network.



3. GRE Tunneling + IP alias The addressing scheme is unified by routing IP traffic over a GRE tunnel between the on-premises network and alias IP addresses assigned to servers on the IBM Cloud . This is a special case of the scenario illustrated in [this tutorial](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-configuring-IPSEC-VPNconfiguring-IPSEC-VPN). An additional interface and IP alias for a compatible IP subnet is created on the virtual and bare-metal servers provisioned on the IBM Cloud, supported by appropriate routing configuration on the VRA.
4. Virtual Overlay Network [IBM Cloud Virtual Private Cloud (VPC)](https://cloud.ibm.com/docs/vpc?topic=vpc-getting-started) supports BYOIP for fully virtual environments on the IBM Cloud. It could be considered as an alternative to the secure private network enclosure described in [this tutorial](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-secure-network-enclosuresecure-network-enclosure).



Alternatively consider a solution such as VMware NSX that implements a virtual overlay network in a layer over the IBM Cloud network. All BYOIP addresses in the virtual overlay are independent of IBM Cloud network address ranges.
[Hosting web applications from a secure private network](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-web-app-private-network)Hosting web applications from a secure private network

This tutorial takes you through the creation of a scalable and secure Internet facing web application hosted in private network secured using a virtual router appliance (VRA), VLANs, NAT and firewalls. The application comprises a load balancer, two web application servers and a MySQL database server. It combines three tutorials to illustrate how web applications can be securely deployed on the IBM Cloud IaaS platform using classic networking.

Virtual Router Appliance IBM Cloud Load Balancer

+1

Virtual Servers for Classic



* 2023-05-05



[Migrating a virtual server between classic data centers](https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-migrating-vsi-new-datacenter)Migrating a virtual server between classic data centers

You have two ways to move your virtual server between IBM Cloud® classic infrastructure data centers:

Virtual Servers for Classic IBM Cloud Load Balancer



* 15 minutes
* 2022-04-15



[Classic bare metal to bare metal or virtual server on VPC using a private network](https://cloud.ibm.com/docs/cloud-infrastructure?topic=cloud-infrastructure-pv-migration-private-network)Classic bare metal to bare metal or virtual server on VPC using a private network

This is the process of migrating from a classic physical bare metal server to a bare metal or virtual server instance on VPC environment. The RackWare Management Module (RMM) solution simplifies the overall migration process of moving the operating system, applications, and data from the classic bare metal to bare metal or virtual server instance on an IBM Cloud® VPC.

Virtual Servers for Classic Virtual Private Cloud (VPC)

+2

Transit Gateway,Building infrastructure



* 25 minutes
* 2022-12-16