vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Tutorial: Setting up the secure network 

This tutorial describes how you can set up the secure network which provides an end to end encrypted network communication for IBM Cloud® Hyper Protect Virtual Servers services. This tutorial is intended for IBM Cloud Hyper Protect Virtual Servers customers. Contact your IBM representative for access to the GitHub repository.



 Contents 



* [Basic concepts](https://cloud.ibm.com/docs/hp-virtual-servers?topic=hp-virtual-servers-tutorial_networkbasicconcept_sn)
* [Before you begin](https://cloud.ibm.com/docs/hp-virtual-servers?topic=hp-virtual-servers-tutorial_networkprerequisites_sn)
* [Task flow](https://cloud.ibm.com/docs/hp-virtual-servers?topic=hp-virtual-servers-tutorial_networktaskflow_sn)
* [Command reference](https://cloud.ibm.com/docs/hp-virtual-servers?topic=hp-virtual-servers-tutorial_networkref_sn)







 Basic concepts 

Some of the key features of the secure network are listed here:



* An end-to-end encrypted network.
* Controlled by the user rather than the cloud provider. The secure network configuration for a virtual server is managed by the user who creates the Hyper Protect Virtual Server instance, and this configuration cannot be modified by the IBM Cloud IAM user, nor by the IBM Cloud operator.



A user with administrator access to the Hyper Protect Virtual Server must set up the entire secure network and can configure multiple users to this role, who have access to the capabilities to manage the secure network and deploy solutions on the secure network.

Zoom

![Secure network architecture diagram](https://cloud.ibm.com/docs-content/v1/content/29e0ddc9fd7149f916889ba6a4d131cc3528c9bc/hp-virtual-servers/image/secure_network_arch.png)

Figure 1. The Secure network architecture



1.
For example, you might choose to set up a [Virtual Router Appliance](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-about-the-vra) or a [Fortigate Security Appliance](https://cloud.ibm.com/docs/vmwaresolutions/services?topic=vmwaresolutions-fsa_considerations).

You can set up your gateway appliance with custom network policies to provide dedicated network security for your cluster and to detect and remediate network intrusion. When you set up a firewall on the public network, you must open up the required ports and private IP addresses for each region so that the master and the worker nodes can communicate. If you also configure this firewall for the private network, you must also open up the required ports and private IP addresses to allow communication between worker nodes and let your cluster access infrastructure resources over the private network. You must also enable VLAN spanning for your account so that subnets can route on the same VLAN and across VLANs.





 Worker communication to other services or networks with a gateway appliance 

To securely connect your worker nodes and apps to an on-premises network or services outside of IBM Cloud, set up an IPSec VPN endpoint on your gateway appliance and the strongSwan IPSec VPN service in your cluster to use the gateway VPN endpoint. If you don't want to use strongSwan, you can set up VPN connectivity directly with VRA.

Your worker nodes can securely communicate with other IBM Cloud services and public services outside of IBM Cloud through your gateway appliance. You can configure your firewall allow access to the public and private IP addresses of only the services that you want to use





 External communication to apps that run on worker nodes with a gateway appliance 

To provide private access to an app in your cluster, you can create a private network load balancer (NLB) or Ingress application load balancer (ALB) to expose your app to the private network only. If you need to provide limited public access to an app in your cluster, you can create a public NLB or ALB to expose your app.
Establish a connection from the jump server or bastion host to your Power Systems Virtual Server instances by using SSH.



This option is typically used to manage infrastructures and is not recommended for production workloads.





 Connecting to an on-premises network by using an internet IPsec VPN connection 

Although individual Power Systems Virtual Server instances can have internet access, there is no site-to-site IPsec VPN service that connects your Power Systems Virtual Server subnets to your remote networks currently available.

Zoom

![IPsec VPN deployment scenario](https://cloud.ibm.com/docs-content/v1/content/1d36273917990fbf48078805e201d2e85e2fcb27/power-iaas/images/network-ipsec-vpn.svg)

Figure 6. IPsec VPN deployment scenario

This deployment topology leverages the IBM Cloud classic infrastructure gateway appliance to provide an internet-connected IPsec VPN gateway to enable a site-to-site VPN connection to your Power Systems Virtual Server resources.



* The IBM Cloud gateway appliance allows you to selectively route private and public network traffic through a full-featured, enterprise-level firewall that is powered by the software features of VyOS, JunOS, or any other operating system (Bring Your Own Appliance) that you choose.
* All appliance features are customer-managed.
* By using the IBM Cloud UI, CLI, or API, you can select your VLANs, and hence, the associated subnets, that you want to associate with your gateway appliance. Associating a VLAN with a gateway appliance reroutes (or trunks) that VLAN and all of its subnets to your appliance, giving you control over filtering, forwarding, and protection.
* A gateway appliance is attached to two nonremovable transit VLANs, one each for your public, and private networks.



Complete the following steps to implement this scenario:



1.
* Classic clusters: Enable a [Virtual Router Function (VRF)](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf) for your IBM Cloud infrastructure account. To check whether a VRF is already enabled, use the ibmcloud account show command. If you can't or don't want to enable VRF, enable [VLAN spanning](https://cloud.ibm.com/docs/vlans?topic=vlans-vlan-spanningvlan-spanning). When a VRF or VLAN spanning is enabled, the Ingress controller can route packets to various subnets in the account.







 Privately exposing apps with a public cloud service endpoint 

Classic clusters

Virtual Private Cloud

If your cluster is created on classic infrastructure, or if your cluster is created on VPC infrastructure and you enabled the public cloud service endpoint during cluster creation, your cluster is created with only a public Ingress controller by default. To privately expose your apps, you must first create a private Ingress controller. Then, you must register your Ingress controller with a subdomain and, optionally, import your own TLS certificate.



 Step 1: Deploy apps and create app services 

Start by deploying your apps and creating Kubernetes services to expose them.



1. [Deploy your app to the cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_apps). Ensure that you add a label to your deployment in the metadata section of your configuration file, such as app: code. This label is needed to identify all pods where your app runs so that the pods are in the Ingress load balancing.
2. For each app deployment that you want to expose, create a Kubernetes ClusterIP service. Your app must be exposed by a Kubernetes service to be included in the Ingress load balancing.



oc expose deploy <app_deployment_name> --name my-app-svc --port <app_port> -n <namespace>





 Step 2: Set up TLS termination with TLS certificates and Kubernetes secrets
Data centers across multiple locations provide resilience in the case of a geographic failure and bring workloads closer to globally distributed users, which reduces latency and increases perceived performance. The IBM Cloud network enables users to link workloads hosted in secure private networks across data centers and locations. Use the following checklist to review the available options and to connect your existing on-premises environments to IBM Cloud.



Table 5. Getting started tasks for connecting your network to IBM Cloud

 Task Description 

 <br><br> * Enable virtual routing and forwarding (VRF)<br><br><br> Dispersed cloud resources are resources in more than one location or in more than one subnet or VLAN. These types of resources require a routing function to communicate among themselves, even within a private network context. New accounts that are created in IBM Cloud have a "multiple isolation" tenancy communication option, which is often called a customer VRF, enabled. Verify that it is enabled in your account, or enable it after confirming potential service disruptions if you have existing resources in your account. Follow the steps in the [Enabling VRF in the console](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpoint&interface=uivrf) documentation. 
 <br><br> * Enable service endpoints<br><br><br> It is also recommended to enable your account for using service endpoints. When IBM Cloud service endpoints are enabled in your account, you can choose to expose a private network endpoint when you create a resource. You can then connect directly to this endpoint over the IBM Cloud private network rather than the public network. Because resources that use private network endpoints don't have an internet-routable IP address, connections to these resources are more secure. Follow the steps that are outlined in [Enabling service endpoints](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpoint&interface=uiservice-endpoint).
Infrastructure management design 

Infrastructure management refers to the components that are managing the VMware® infrastructure.



* The VMware vCenter Server® with an embedded Platform Services Controller (PSC) is the centralized platform for managing VMware vSphere® environments and is one of the fundamental components in this solution.
* The PSC is used in this solution to provide a set of infrastructure services, which include VMware vCenter Single Sign On, license service, lookup service, and VMware certificate authority.



This design uses a PSC function that is integrated into an instance of vCenter Server. The PSC and vCenter Server are housed within the same virtual machine (VM).

Zoom

![Infrastructure management](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/vcsv4radiagrams-ra-inframgmt.svg)

Figure 1. Infrastructure management

The PSC located in the primary instance is assigned the default SSO domain of vsphere.local.



 vCenter Server design 

The vCenter Server with an embedded PSC is installed on a portable subnet on the private VLAN that is associated with management VMs. Its default gateway is set to the IP address assigned on the BCR for that particular subnet. The virtual appliance is configured with the specifications in the following table.



Table 1. vCenter Server Appliance specifications

 Attribute Specification 

 vCenter Server Virtual appliance 
 Appliance installation size Medium (up to 400 hosts or 4,000 VMs) 
 Platform Services Controller Integrated 
 Number of vCPUs 8 
 Memory 28 GB 
 Disk 700 GB on local datastore (Large disk deployment) 
 Disk type Thin provisioned 





 vCenter Server database 

The vCenter Server configuration uses a local, embedded PostgreSQL database that is included with the appliance. The embedded database is used to remove any dependencies on external databases and licensing.





 vCenter Server cluster specification
If you want to separate different types of network traffic in your landscape, you can order more subnets (and their respective VLANs).

Keep in mind that the additional VLANs and subnets lead to traffic segregation, not increased performance; the increased performance is gained when additional VLANs and Subnets are associated to a host. When multiple network interfaces are used, two performance increases are possible depending on the use case:



* Bonding of the network interfaces, creating a network path with the network throughput of both interfaces
* Traffic segregation using two networks, then isolating high volumes of traffic to a specific network which avoids a single network becoming a bottleneck. For example, a network for storage I/O only



With IBM Power Virtual Server as an example, a single threaded Linux network interface may reach 100% CPU Thread utilization even though the performance limits of the network path itself are still not reached. Additional network interfaces attached to another VLAN and Subnet will therefore increase performance

By default, your server has a Private IP address. If you use public subnets, a public IP address is assigned in addition.





 Networking connectivity 

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.

If you need to connect to your virtual server through the public internet, in other words, inbound to a virtual server, you can order Public IPs and attach them to the virtual server per vNIC.

Various interconnectivity options available, for example:



* IBM Power Systems Infrastructure bridged to IBM Cloud Classic Infrastructure
* IBM Power Systems Infrastructure bridged to IBM Cloud VPC Infrastructure
* IBM Power Systems Infrastructure bridged to on-premises data centers by using IBM Direct Link



IBM Cloud Direct Link on Classic must be used to connect your IBM Power Systems Virtual Servers with your IBM Cloud Classic Infrastructure and VPC Infrastructure resources.

After you configure Direct Link on Classic, you must configure routing on your virtual server instance.

Direct Link on Classic is also used for closer integration into your backbone infrastructure, for more information, see [Connectivity to your SAP system landscape](https://cloud.ibm.com/docs/sap?topic=sap-determine-access).
For more information, see [Working with vApps](https://docs.vmware.com/en/VMware-Cloud-Director/10.1/VMware-Cloud-Director-Tenant-Portal-Guide/GUID-AC48FB5E-4ADC-4835-AACE-B949B297A147.html).



1. From the tenant portal, click the Menu icon at the upper left of the page and select Data Centers.
2. From the main page under Virtual Data Center, click the virtual data center where you would like to create the vApp network.
3. In the left pane under Compute, click vApps.
4. Click Details on the vApp you would like to add a vApp network to.
5. Click the Network tab, and click New in the vApp Fencing section.
6. Select vApp Network.
7. Complete the Name and Gateway CIDR fields. For example, Web and 192.168.33.1/24.
8. (Optional) Provide the DNS information.
9. Leave the Static IP Pools section blank.
10. Set the slider to Connect to an organization VDC network.
11. Click Add.



For more information, see [Working with networks in a vApp](https://docs.vmware.com/en/VMware-Cloud-Director/10.1/VMware-Cloud-Director-Tenant-Portal-Guide/GUID-FCBC791B-3183-4CD9-A194-856E98CC32D3.html).





 Creating a vApp Network for VMware as a Service 

If not already completed, create a vApp containing at least two VMs.
VMware DRS and reservations 

Because it provides time–sensitive networking services, FortiGate VM must be configured to ensure that it has adequate resources. The IBM Cloud automation configures a reservation to ensure that the virtual appliances receive their full allotment of CPU and memory. To assure high availability, the IBM Cloud automation also creates a DRS anti–affinity rule to restrict the two FortiGate VM virtual appliances from running on the same host.





 License requirements 

This architecture requires FortiGate VM licensing from Fortinet®. IBM Cloud automation provisions the FortiGate VM license based on your chosen license tier and deployment size. Your IBM Cloud monthly bill reflects your order and ongoing usage of FortiGate VM. The FortiGate virtual appliances require outbound connectivity to Fortinet licensing servers to activate and maintain their license.





 Caveats 

It is not possible to change the licensing tier or licensed throughput of your FortiGate VM deployment after it is deployed. To achieve this scenario, you must deploy a new instance of FortiGate VM, migrate your configuration to the new instance, and delete the original instance.





 Related links 



* [Solution overview](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-fortigate-overview)
* [Solution design](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-fortigate-design)
* [FortiGate–VM on VMware ESXi data sheet](https://www.fortinet.com/content/dam/fortinet/assets/data-sheets/FortiGate_VM_ESXi.pdf)
Using secondary subnets on self-hosted VMs 

If you host your own virtual machines on the IBM Cloud® network, you'll need secondary subnets to provide the instances with IP addresses. The following scenario shows a flexible way to provide your VMs IP addresses by using one or more virtual machine hosts, whether participating in clustered configurations or not.

Suppose you have two bare metal servers, named baremetal1 and baremetal2. Both are host to your own virtual machines, and each already has their own IP addresses assigned from a primary subnet. You need additional IP addresses for your virtual machines. You can use any type of secondary subnet to achieve that, but it is recommended to use a secondary portable subnet as the source of addresses used by your VMs. A portable subnet provides both bare metals access to the IP addresses defined by the subnet. This way, you can share those IP addresses across both servers, and if you use migration techniques for your VMs, can transfer VMs across those servers seamlessly.

Now let's say you've created two virtual machines, VPS1 and VPS2, purchased portable subnet 129.42.0.0/29, and assigned two addresses from it to your virtual machines. The IP address utilization looks something like this:

129.42.0.0/29 - Secondary portable subnet

129.42.0.0 – Network
129.42.0.1 – Gateway
129.42.0.2 –
129.42.0.3 – VPS1
129.42.0.4 –
129.42.0.5 – VPS2
129.42.0.6 –
129.42.0.7 – Broadcast

If you want VPS1 to have more IP addresses to separate services that it is providing, you can assign more addresses out of the 129.42.0.0/29 subnet, but you may want to use that subnet only to bring VMs online, not for their services. You have two options: 1) purchase another portable subnet, or 2) purchase a static subnet. Portable subnets provide flexibility but they don't give you access to all of the IP addresses.
: It is run by moving the production to the DR site. From the network perspective, this is equivalent to the real emergency. The entire production networks must be routed to the DR site, while the replication network flow is reversed (from DR site to on premises) to bring the update back to the on premises, which now works as the DR site.

In the cloud, the network for testing is provisioned as part of the DR cloud resources and is often subject to limitations as mentioned before. If the DR is implemented on the same cloud, it would be easier to configure a network to simulate or switch the production environment.





 Failover (or emergency) 

The entire production networks must be routed to the DR site, while the replication network flow is reversed from DR site to on premises to bring the update back to the on premises, and suspended until the emergency is over at on-premises site.

During the emergency, the network functions (routing and security) are also transferred from on premises to the DR site, and if the primary is physical on premises, it might need to be virtualized to adapt to the target requirements. A precheck and maintenance of this physical-to-virtual network function is a key success factor during the emergency, and it has the same importance as the data replicator or the server reprovisioning technique.

For this network, also apply all the considerations described previously for cloud to DR cloud.





 Fallback 

Fallback presents the same challenges as the DR simulation by switch-over seen before, as you keep having the production running at the DR site, while intercepting and sending updates back to the fallback site. The quantity of data that flows back to the fallback sites depends on the emergency that happened.

For short-term emergencies where the original site is unavailable for a period of time, but servers and storage remain intact, a delta-resynch might fit the need to bring the operation back to on premises.

For other emergencies, that have forced a change to the site, server, or storage in the original on premises, it might require a full resynchronization of data, so the fallback will happen tidily at the most convenient time after the sync point has been achieved.





 Cloud networking (LAN)
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. The popular strongSwan VPN Gateway is used to represent the on-premises VPN gateway.

Schematics Virtual Private Cloud (VPC)

+3

Object Storage,Databases For PostgreSQL,DNS Services



* 2 hours
* 2023-05-08



[Deploying IBM WebSphere Application Server](https://cloud.ibm.com/docs/was-for-vsi?topic=was-for-vsi-getting-started)Deploying IBM WebSphere Application Server

The Deploying IBM WebSphere Application Server tutorial describes how you can use IBM WebSphere Application Server to install a WebSphere Application Server traditional environment on one or more Red Hat® Enterprise Linux® 8.4 virtual server instances (VSIs) on IBM Cloud®.

WebSphere Application Server



* 2021-10-20



Integration[Provisioning Event Streams for Satellite](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-satellite-provisioning)Provisioning Event Streams for Satellite

Complete the steps to set up the IBM Cloud Satellite® plan for IBM® Event Streams for IBM Cloud® in a Satellite location.

Event Streams



* 15 minutes
* 2022-12-13



[Process big data logs with SQL](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-big-data-log-analytics)Process big data logs with SQL

In this tutorial, you will build a log analysis pipeline designed to collect, store and analyze log records to support regulatory requirements or aid information discovery. This solution leverages several services available in IBM Cloud: Event Streams, Object Storage, Data Engine (previously SQL Query), Key Protect, and IBM Analytics Engine. A script and tool will assist you to simulate the transmission of web server log messages from a static file to Event Streams.

Object Storage Event Streams

+3

Analytics Engine,Data Engine,Key Protect



* 3 hours
[Close icon](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/icons/close-icon.svg) to delete the adapter. Click OK.
4. Return to the Virtual Switches panel and click Add Networking.



1. Select Virtual Machine Port Group for a standard switch and click Next.
2. For New Standard Switch, set the MTU to 9000 and click Next.
3. Click the green Add icon ![Add icon](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/icons/add.svg) to add an adapter. Click OK, then Next to accept vmnic2.
4. For Connection Settings, keep the VM Network and VLAN ID None defaults. Click Next, then Finish. Standard Switch: vSwitch0 is displayed in the list of switches.



5. Make a note of the Network Setting for the vCenter Server Appliance VM. You must update the new vCenter appliance to match.



* From the vCenter Server user interface, click the VM for the vCenter appliance. Note the name, ending with vc.
* From the middle pane, click the Networks tab. Note the name of the distributed port group, ending with -dpg-mgmt.









 Procedure to upgrade vCenter Server 

Follow the VMware instructions for upgrading vCenter. For more information, see [Upgrade a vCenter Server Appliance 6.5 or 6.7 with an embedded Platform Services Controller by using the GUI](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vcenter.upgrade.doc/GUID-6A5C596D-103E-4024-9353-5569263EB427.html).