| copyright | lastupdated | keywords | subcollection | ||
|---|---|---|---|---|---|
|
2021-05-27 |
SAP, {{site.data.keyword.cloud_notm}} SAP-Certified Infrastructure, {{site.data.keyword.ibm_cloud_sap}}, SAP Workloads |
sap |
{:shortdesc: .shortdesc} {:codeblock: .codeblock} {:screen: .screen} {:external: target="_blank" .external} {:pre: .pre} {:table: .aria-labeledby="caption"} {:note: .note} {:tip: .tip} {:important: .important}
{: #vpc-env-introduction}
An Infrastructure-as-a-Service (IaaS) environment consists of many components - primarily compute, storage, and network from a specified region (such as the US) and a designated site location (also referred to as zone, which is a data center site).
{: #vpc-env-deployment-and-management}
IBM VPC Infrastructure offerings, such as Virtual Servers (Gen2), are deployed through the {{site.data.keyword.cloud_notm}} VPC Infrastructure console.
Alternatively, deployments can be made and managed by using:
- {{site.data.keyword.cloud_notm}} CLI
- {{site.data.keyword.cloud_notm}} VPC Infrastructure API calls that use an {{site.data.keyword.cloud_notm}} API key
- Terraform Provider for {{site.data.keyword.cloud_notm}} by using an {{site.data.keyword.cloud_notm}} API key
For more information, see Managing VPC Infrastructure (IAM).
{: #vpc-env-locations-availability-zones}
With availability zones across North and South America, Europe, Asia, and Australia, you can provision cloud resources where (and when) you need them. Many regions are avilable globally, with multiple availability zones (often Zone 1, Zone 2, and Zone 3 to begin with) in each region. Each availability zone is connected to the {{site.data.keyword.cloud_notm}} global private network, making data transfers faster and more efficient anywhere in the world.
For more information about {{site.data.keyword.cloud_notm}} availability zones, data centers, and points of presence (PoPs), see the global regions, availability zones, and data centers map{: external}.
{: #vpc-env-networking}
The {{site.data.keyword.vpc_short}} infrastructure network, is robust, secure, and flexible; powered by the latest in networking hardware, with the best networking capabilities.
| {{site.data.keyword.cloud_notm}} VPC Infrastructure network |
|---|
| Global |
| Resource Group |
| Region |
| VPC |
| Availability zone (with address prefix) |
| Subnet |
| {: caption="Table 1. Networking component layers overview" caption-side="top"} |
The VPC Infrastructure provides functions that are called {{site.data.keyword.vpc_full}}, which allows definable isolation and creation of a network within the Cloud.
Every {{site.data.keyword.vpc_full}} is created for a Region, and spans multiple availability zones.
When you deploy a VPC in an availability zone, an address prefix is used for that specified zone.
Each VPC Zone (and the address prefix) contains one or many subnets. You can define each subnet manually by choosing the IP range and the subnet mask, or you can choose the number of IP addresses needed.
Resources are deployed into this subnet.
{: #vpc-env-networking-connectivity}
{{site.data.keyword.vpc_full}} network overview demonstrates the connectivity for the environment. Issues with network connectivity can cause delays for your project if you do not plan properly, regardless of how you plan to use your system.
In general, {{site.data.keyword.cloud_notm}} VPC has a highly available, high-bandwidth network that is connected to every physical server, which serves the hypervisor. Each physical server (host) has a hypervisor that divides the network into virtual network interfaces (vNICs) that are attached to the virtual server.
Depending on the profile of your virtual server, the total available network bandwidth to the virtual server is in the range of 4 Gbps to 64 Gbps. It's important to consider that each vNIC has a maximum throughput of 16 Gbps, so to achieve maximum throughput, up to 4 additional vNICs must be attached to the virtual server (i.e. a virtual server may have maximum 5 vNICs attached).
If you need to connect to your virtual server through the public internet (in other words, inbound to a virtual server), you can order a Floating IP and attach to the virtual server's vNIC (i.e. 1 Floating IP per virtual server).
If you want to connect to the public internet from your virtual server (in other words, outbound from a virtual server), you need to attach a Public Gateway to the VPC. This gateway provides access to the internet for an entire subnet.
The following interconnectivity options available:
- VPC zone to zone,
- VPC to VPC,
- VPC to Classic Infrastructure,
- VPC to {{site.data.keyword.IBM_notm}} Power Systems Infrastructure,
- VPC to on-premises data centers by using a VPC VPN Gateway
When a connection to the public internet is not acceptable because of security measures, you can deploy an IPsec Gateway into your VPC to connect to your virtual server. For more information, see Connectivity to your SAP system landscape - VPC VPN Gateway. Or, you can have an even closer integration into your backbone infrastructure by an {{site.data.keyword.cloud_notm}} Direct Link. For more information, see Connectivity to your SAP system landscape - {{site.data.keyword.cloud_notm}} Direct Link.
Server resources that are in {{site.data.keyword.cloud_notm}} Classic Infrastructure can be connected through Transit Gateways. These virtual devices are used to connect your private VLAN subnets in the Classic Infrastructure to your VPC subnets.
For more information, see About Networking for VPC and Setting up access to classic infrastructure.
Extra requirements exist in Classic Infrastructure networking to enable the Transit Gateway, be sure to review documentation before you change your Classic Infrastructure or VPC Infrastructure networking topology and configuration. {:important}
It is advised that your networking department contact {{site.data.keyword.cloud_notm}} Support after determining the layout of your landscape and the connectivity that is required on the SAP application layer. {: note}
{: #vpc-env-networking-protection}
{{site.data.keyword.cloud}} offers further protection mechanisms that can provide your {{site.data.keyword.vsi_is_short}} with a layer of security that you can configure and adapt anytime. Two key principles are:
- Network Access Control Lists (ACL): Available for use by all subnets in all zones. ACLs attach to a subnet and provide subnet-level protection by limiting a subnet's inbound and outbound traffic.
- Security Groups: Available for use by all subnets on all zones that are attached to a vNIC of any virtual server that provides instance-level protection by acting as a firewall to restrict a vNIC inbound and outbound traffic.
For more information, see Security in your VPC.
{: #vpc-env-networking-multiple-subnets}
If you want to separate different network traffic types in your landscape, either because of security restrictions or because of throughput considerations, you can configure and attach multiple subnets to your VPC.
{: #vpc-env-networking-acl}
Network Access Control Lists (ACLs) are used to manage allow and deny rules on a subnet level. ACLs are used to manage network traffic between subnets, too. The default ACL for a subnet opens the subnet for all traffic. If you wanted more strict security measures, you would need to add rules to the ACL. When you add rules, keep in mind that required services like DNS or OS patch and packages downloads might be affected by those rules. For more information, see Security in your VPC.
{: #vpc-env-networking-security-groups}
A Security Group is a set of allow-only firewall rules. You can apply these rules to one or more virtual servers. You can also create a default Security Group with Secure Shell (SSH) and ICMP (ping) during VPC creation, which allows ICMP and SSH from any IP address. These rules need to restrict the IP ranges from which you are planning to access the VPC. If you plan to access these ports through the public internet, set rules to allow for SAP application ports.
{: #vpc-env-storage}
Only Block Storage with a specified IOPS threshold is available with Virtual Servers.
Block storage is provided with your Virtual Servers and uses input/output operations per second (IOPS) to determine storage needs. It is ideal for storage-intensive applications with high I/O needs, such as an OS, and database and application software. This option is the perfect companion for SAP HANA workloads.
All Block storage is selected based on capacity (GB) and performance (IOPS) measurements and is required to meet a specific SAP Workload.
IOPS values are measured based on 16 KB block size with a 50-50 read/write mix. To achieve a maximum I/O throughput, it's advisable to look at the tier and custom profiles available for storage and find the optimal combination of size and IOPS.
Storage volumes differ in performance, depending on their IOPS tier. You can select among 3, 5, and 10 IOPS/GB (see Tiered IOPS profiles). You can also select a custom size (in GB and IOPS) that is based on the size of the storage.
If you need more than the initially provisioned storage in your virtual server, you can attach extra volumes to a virtual server later. Contact {{site.data.keyword.cloud_notm}} Support for extension options if the attached storage is insufficient for your workload.
{: #vpc-env-shared-storage}
Block storage can be detached and attached to other virtual servers at any time, but, only to one virtual server at the same time.
No shared storage for virtual servers is available in VPC at time of writing.
{: #vpc-env-compute}
There is only one type of IaaS available within the VPC Infrastructure environment:
- Intel Virtual Servers
For more information, see Infrastructure certified for SAP.