vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* The Subnet flow log collector (green) is also an umbrella collector, but for a specific subnet within a VPC. Any instances in this subnet, or in the future within this subnet, flow into Bucket-C.
* The Instance flow log collector (red) is used when you need even finer granularity. For example, suppose that Instance-5 was using Bucket-E and you are trying to troubleshoot a connectivity issue on a specific instance. You can narrow down your troubleshooting by creating a flow log collector just for that instance, sending all its traffic to a separate bucket for a certain amount of time.

Zoom

![Finest granularity wins example](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc//images/fl-granularity.png)

Figure 1. Finest granularity wins example







 Use case 3: Troubleshooting security groups and network ACLs 

Similar to use case 2, this use case illustrates how to set the granularity of flow log collectors for different target scopes. It also goes one step further to depict how flow logs can help you troubleshoot by using security groups and network ACLs (NACLs).

Scenario:



1. NACL 2 on Subnet 3 is preventing you from running a web server there. Notice that this network ACL allows ingress, but denies egress.
2. A virtual server instance on Subnet 2 (NACL 1 allows ingress and egress) tries to query the web server that you are running on Subnet 3.
3. The query gets through and you see that the traffic is accepted on the ingress path to Subnet 3 into virtual server instance 31.
4. When virtual server instance 31 receives the request, it generates a reply and tries to send it. Unfortunately, the response cannot be returned and your connection hangs on Subnet 2 until it times out.
5. Flow logs show that the request was sent and that it was accepted on virtual server instance 31.
Step two: Create the ordering service 

In other distributed blockchains, such as Ethereum and Bitcoin, there is no central authority that orders transactions and sends them out to peers. Hyperledger Fabric, the blockchain that the IBM Blockchain Platform is based on, works differently. It features a node, or a cluster of nodes, called an ordering service.

The ordering service is a key component in a network because it performs a few essential functions:



* It literally orders the blocks of transactions that are sent to the peers to be written to their ledgers. This process is called "ordering".
* On orderers with a system channel, it maintains the consortium, the list of peer organizations permitted to create channels, resides.
* It enforces the policies decided by the consortium or the channel administrators. These policies dictate everything from who gets to read or write to a channel, to who can create or modify a channel. For example, when a network participant asks to modify a channel or consortium policy, the ordering service processes the request to see if the participant has the proper administrative rights for that configuration update, validates it against the existing configuration, generates a new configuration, and relays it to the peers.



For more information about ordering services and the role they play in networks based on Hyperledger Fabric, see [The Ordering Service](https://hyperledger-fabric.readthedocs.io/en/release-2.2/orderer/ordering_service.html).

In a paid cluster, you have the option between creating a one node ordering service (sufficient for testing purposes) and a crash fault tolerant ordering service featuring five nodes tied to a single organization. In a free cluster, you will only be able to create a single node ordering service. In this tutorial, we will show the one node ordering service.

However, just as with the peer, before we can create an ordering service, we need to create a CA to supply the identities and the MSP of our ordering service organization.
A Virtual Private Cloud (VPC) provides network isolation and security in the IBM Cloud. A VPC can be a building block that encapsulates a corporate division (marketing, development, accounting, ...) or a collection of microservices owned by a DevSecOps team. VPCs can be connected to an on-premises enterprise and each other. This may create the need to route traffic through centralized firewall-gateway appliances. This tutorial will walk through the implementation of a hub and spoke architecture depicted in this high-level view:

Virtual Private Cloud (VPC) Transit Gateway

+1

Direct Link on Classic



* 2 hours
* 2023-05-05



[Centralize communication through a VPC Transit Hub and Spoke architecture - Part two](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-transit2)Centralize communication through a VPC Transit Hub and Spoke architecture - Part two

A layered architecture will introduce resources and demonstrate connectivity. Each layer will add additional connectivity and resources. The layers are implemented in Terraform. It will be possible to change parameters, like number of zones, by changing a Terraform variable. A layered approach allows the tutorial to introduce small problems and demonstrate a solution in the context of a complete architecture.

Virtual Private Cloud (VPC) Transit Gateway

+4

Direct Link on Classic,DNS Services,IBM Cloud Databases,Databases For Redis



* 2 hours
* 2023-05-05



[Connecting Locations with IBM Cloud using Direct Link](https://cloud.ibm.com/docs/satellite?topic=satellite-direct-link-tutorial)Connecting Locations with IBM Cloud using Direct Link

Use a secure IBM Cloud® Direct Link connection for Satellite Link communications between your services running in an IBM Cloud Satellite® Location and IBM Cloud®.

Satellite Kubernetes service

+1

Direct Link



* 2 hours
* 2023-07-05
All of the nodes in the HPC cluster have the same public key that you register at your cluster creation. You can use ssh-agent forwarding, which is a common technique to access remote nodes that have the same public key. It automates to securely forward private keys to remote nodes. Forwarded keys are deleted immediately after a session is closed.

To securely forward private keys to remote nodes, you need to do ssh-add and ssh -A.

[your local PC]$ ssh-add {id_rsa for symphony cluster}
[your local PC] ssh -A -J root@jumpbox_fip root@management_private_ip
...
[root@management] ssh -A worker_private_ip

For Mac OS X, you can persist ssh-add by adding the following configuration to .ssh/config:

Host 
  UseKeychain yes
  AddKeysToAgent yes

You can even remove -A by adding "ForwardAgent yes" to .ssh/config.
* How many worker nodes can I deploy in my Spectrum Symphony cluster through this offering?

Before deploying a cluster, it is important to ensure that the VPC resource quota settings are appropriate for the size of the cluster that you would like to create (see [Quotas and service limits](https://cloud.ibm.com/docs/vpc?topic=vpc-quotas)).

The maximum number of worker nodes that are supported for the deployment value worker_node_max_count is 500 (see [Deployment values](https://cloud.ibm.com/docs/hpc-spectrum-symphony?topic=hpc-spectrum-symphony-deployment-values)). The worker_node_min_count variable specifies the number of worker nodes that are provisioned at the time that the cluster is created, which will exist throughout the life of the cluster. The delta between those two variables specifies the maximum number of worker nodes that can either be created or destroyed by the Symphony Host Factory auto-scaling feature.

The Spectrum Symphony offering supports both bare metal worker nodes and Spectrum Scale storage nodes. The following combinations of values are supported:
A smart contract proposal contains a smart contract definition name, version, package, endorsement policy, and optionally a private data collection.





 Quorum 

In a Raft ordering service, a quorum represents the number of nodes that must be available for transactions to be processed. This number is a majority of the total number of nodes in the consenter set of the channel. In other words, if you have one node, you need that node available to have a quorum, because the majority of one is one. Similarly, if you have two nodes, you will need both available, since the majority of two is two (for this reason, a configuration of two nodes is discouraged; there is no advantage to a two node configuration). In a similar vein, the majority of three is two, the majority of four is three, the majority of five is three, and so on.





 Raft 

Raft is a crash fault tolerant (CFT) ordering service based on an implementation of [Raft protocol](https://raft.github.io/raft.pdf) in etcd. Raft follows a “leader and follower” model, where a leader node is elected (per channel) and its decisions are replicated by the followers. Raft ordering services should be easier to set up and manage than Kafka-based ordering services and a cluster of these nodes can be created using the IBM Blockchain Platform.





 SDK 

Hyperledger Fabric Client Software Development Kits (SDKs) enable interaction between your client application and your blockchain network. Fabric supports three SDKs: [Go](https://github.com/hyperledger/fabric-sdk-go), [Node](https://github.com/hyperledger/fabric-sdk-node), and [Java](https://github.com/hyperledger/fabric-sdk-java)) that include documentation for the available APIs.





 Service credentials 

Service credentials are in JSON format and contain the API endpoint information and enrollIDs/secrets for your network resources, that is, CAs, ordering nodes, and peers. Your application interacts with network resources through these API endpoints.





 Service discovery
If your apps require more resources than you have available on your worker node, use a different worker node flavor that can fulfill these requirements. You know that your worker nodes are overloaded when they frequently report back a status of NotReady or evict pods due to the lack of memory or other resources.
* Larger versus smaller worker node flavors: Larger nodes can be more cost efficient than smaller nodes, particularly for workloads that are designed to gain efficiency when they process on a high-performance machine. However, if a large worker node goes down, you need to be sure that your cluster has enough capacity to safely reschedule all the workload pods onto other worker nodes in the cluster. Smaller worker can help you scale safely.
* Replicas of your app: To determine the number of worker nodes that you want, you can also consider how many replicas of your app that you want to run. For example, if you know that your workload requires 32 CPU cores, and you plan to run 16 replicas of your app, each replica pod needs 2 CPU cores. If you want to run only one app pod per worker node, you can order an appropriate number of worker nodes for your cluster type to support this configuration.









 How do I monitor resource usage and capacity in my cluster? 

Now that you have a good estimate of your app size and the worker nodes that you need to run your workload, you can deploy your app and continuously monitor performance to maximize your compute resource usage.



1. [Create your cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-clusters) with the worker pool flavor and number of worker nodes that you [previously estimated](https://cloud.ibm.com/docs/openshift?topic=openshift-strategysizing_workers).
2. Review what compute resources your cluster uses by default and calculate the remaining cluster capacity that you can use for your workloads.



1. With the IBM Cloud IAM Manager service access role for the cluster in all namespaces: [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
2.
What is Citrix XenServer? 

XenServer is a server virtualization platform that offers virtualization performance for virtualized server and client operating systems that nearly matches the performance of bare metal servers.

XenServer uses the Xen hypervisor to virtualize each server, on which it is installed, enabling each to host multiple virtual machines simultaneously with great performance. You can also use XenServer to combine multiple Xen-enabled servers into a powerful resource pool, by using industry-standard shared storage architectures and by using resource clustering. In doing so, XenServer enables seamless virtualization of multiple servers as a resource pool. These resources are dynamically controlled to deliver optimal performance, increased resiliency and availability, and maximum use of data center resources.

IT managers can use XenServer to create multiple clusters of resource pools and manage the clusters and their resources from a single point of control. With XenServer, a rack of servers can become a highly available compute cluster that protects key application workloads by using industry standard storage architectures. XenServer also offers no-downtime maintenance by moving virtual machines while they are running between machines in the cluster. XenServer extends the most powerful abstraction: virtualization across servers, storage, and networking to enable users to realize the full potential of a dynamic, responsive, efficient data center environment for Windows and Linux workloads.
Adding static routes to worker nodes 

Create static routes on your worker nodes by enabling the static routes add-on for Red Hat® OpenShift® on IBM Cloud® clusters.



 About static routes 

When you configure your cluster network to communicate with other networks over the private network, you might need to add custom static routes on your worker nodes. Static routes allow worker nodes to successfully re-route response packets from your cluster to an IP address in on-premises data center through a VPN or a gateway appliance.

For example, you might use a VPN to connect your cluster to an on-premises data center over the private network. Additionally, your private VPN connection preserves the source IP address in requests between the cluster and the data center.

When an on-premises service sends a request to an app in your cluster, the worker node that your app pod is on drops the response due to reverse path filtering (RPF). RPF is a Linux kernel feature that drops any responses to IP addresses that are not listed in the worker node's routing tables. The response is dropped because the on-premises IP address that was preserved in the request is not routable by the worker node.

In this case, you can create a static route so that when a source IP address from a request is from one of your on-premises subnets, the response is sent to the VPN gateway IP address instead. By adding this static route to the worker nodes' routing tables, you ensure the following:



* Response packets are not dropped due to RPF, because a routing rule that points to the on-premises IP address exists.
* Response packets are successfully routed first through the VPN gateway IP address, and then re-routed to your on-premises IP address.



The static route cluster add-on can be used to apply and manage static routes only. You are responsible for configuring and managing your own VPN, gateway appliance, or IBM Cloud® Direct Link connection.





 Enabling the static route add-on 

To get started with static routes in Red Hat OpenShift on IBM Cloud, enable the static route add-on.

Before you begin
* Mirroring throughput: The bytes per second of mirroring throughput from the source Event Streams instance. This is useful to see whether mirroring is active and for capacity planning.
* Mirroring latency: The per-topic mirroring latency in second from the source Event Streams instance. This is useful to determine how far behind a topic on the target cluster is.



Data that is produced within the latency window might not be present on the target cluster yet and still might be lost if a disaster happens on the source cluster. However, if mirroring is up to date, failing over while both clusters stay healthy can be achieved without any data loss.





 Understanding recovery objectives with mirroring 

In a data protection plan such as mirroring, recovery point objective (RPO) and recovery time objective (RTO) are key parameters. You must understand the decisions that are associated with these objectives.

You can monitor the recovery point objective by using the mirroring latency metric that is provided in the Mirroring dashboard. This metric shows the lag between both clusters, so you can estimate the amount of data loss if a disaster occurs. You are responsible for monitoring that value and ensuring that it fits in your RPO.

The recovery time objective is fully controlled by users and is made of the following timing windows:



* The time that it takes the user to decide to fail over.
* The time that it takes the user to fail over their applications.





 Testing 

Test failing over and back when you made your applications mirroring aware. Complete the steps that are outlined in the [Disaster recovery example scenario](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-disaster_recovery_scenario) and use the Monitoring dashboards to ensure that all steps complete as expected.







 Deleting and re-creating topics with the same name on the source cluster 

When topics are deleted on the source cluster, the corresponding topic on the target cluster is not automatically deleted. If you delete a topic on the source cluster and then re-create a topic of the same name, replication of topic might not start immediately. Therefore, if you intend to re-create the source topic, delete the corresponding topic on the target cluster before you re-create the topic on the source cluster.
(https://cloud.ibm.com/docs/openshift?topic=openshift-roks_ts_subdomainroks_ts_subdomain)

[Why does my worker node show a NetworkUnavailable error?](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-network-calico-nodets-network-calico-node)



* [Workarounds for calico-node](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-network-calico-nodets-network-calico-node-work)



[I deleted a portable subnet and now my Classic cluster my Load Balancers are failing. How do I recover?](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-network-subnet-recoverts-network-subnet-recover)

[Why am I running out of SNAT ports for egress connections from pods in my cluster?](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-network-snat-125ts-network-snat-125)

[Why am I seeing egress connection failures from pods?](https://cloud.ibm.com/docs/openshift?topic=openshift-ts-network-egress-124ts-network-egress-124)

[Why can't I establish VPN connectivity with the strongSwan Helm chart?](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_vpn_failscs_vpn_fails)

[Why can't I install a new strongSwan Helm chart release?](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_strongswan_releasecs_strongswan_release)

[Why does strongSwan VPN connectivity fail after I add or delete worker nodes?]
You can use and manage the cross-regional snapshot in the target region independently from the parent volume or the original snapshot.

Creating a cross-regional copy affects billing. You're charged for the data transfer and the storage consumption in the target region separately.

You can create and manage cross-regional snapshot copies in the UI, from the CLI, with the API, or Terraform.





 Tags for Block Storage for VPC snapshots 

You can apply [user tags](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-about&interface=uisnapshots-about-user-tags) and [access management tags](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-about&interface=uisnapshots-about-mgt-tags) to snapshots of your Block Storage for VPC volumes to better control and organize them across the VPC.



 User tags for snapshots 

User tags are uniquely identified by a Cloud Resource Name (CRN) identifier. When you create a user tag, you provide a unique name within your billing account. You can define user tags in label or key-value format. You can create user tags or add existing tags to snapshots. You can also add tags when you use a snapshot of a volume during [instance creation](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-manage&interface=uisnapshots-vpc-instancevol-tags-ui).
If you need high-performance computing for data- or RAM-intensive workloads, consider creating classic clusters with [bare metal](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodesbm) worker nodes.



 Planning considerations for VMs 



 Do I want to use shared or dedicated hardware? 

When you create a standard classic cluster, you must choose whether you want the underlying hardware to be shared by multiple IBM customers (multi tenancy) or to be dedicated to you only (single tenancy). VPC standard clusters can be provisioned on shared infrastructure (multi tenancy) only.

When you create a standard cluster, you must choose whether you want the underlying hardware to be shared by multiple IBM customers (multi tenancy) or to be dedicated to you only (single tenancy).



* In a multi-tenant, shared hardware setup: Physical resources, such as CPU and memory, are shared across all virtual machines that are deployed to the same physical hardware. To ensure that every virtual machine can run independently, a virtual machine monitor, also referred to as the hypervisor, segments the physical resources into isolated entities and allocates them as dedicated resources to a virtual machine (hypervisor isolation).
* In a single-tenant, dedicated hardware setup: All physical resources are dedicated to you only. You can deploy multiple worker nodes as virtual machines on the same physical host. Similar to the multi-tenant setup, the hypervisor assures that every worker node gets its share of the available physical resources.



Shared nodes are usually less costly than dedicated nodes because the costs for the underlying hardware are shared among multiple customers. However, when you decide between shared and dedicated nodes, you might want to check with your legal department to discuss the level of infrastructure isolation and compliance that your app environment requires.

Some classic worker node flavors are available for only one type of tenancy setup. For example, m3c VMs can be provisioned in a shared tenancy setup only.





 How does bandwidth allocation work for VPC Gen 2 worker nodes? 

Note that Red Hat OpenShift on IBM Cloud doesn't support adjusting the bandwidth profile that is associated with the underlying VPC instance profile.
If there are no errors them create a WSFC cluster with a name of wsfc01 which includes the two SQL servers <hostname1> and <hostname2>. The -ManagementPointNetworkType Distributed option uses the node IP address of the virtual server which means that secondary IP addressing on the interface is not required. This option creates a Distributed Network Name (DNN), which routes traffic to the appropriate clustered resource.
4. The cluster quorum is then configured for Node and Disk Majority using a file share on fs01, \fs01clusterwitness-wsfc01

$sqldb01 = "<hostname1>"
$sqldb02 = "<hostname2>"
Test-Cluster -Node $sqldb01, $sqldb02
New-Cluster -Name wsfc01 -Node $sqldb01, $sqldb02 -ManagementPointNetworkType Distributed
Set-ClusterQuorum -NodeAndFileShareMajority \fs01clusterwitness-wsfc01
Enable-SqlAlwaysOn -ServerInstance sqldb01, sqldb02 -Force



This activity does not have to be repeated on the second node





 Create a file share 

The database to be replicated must be backed up and restored to the secondary instances, a file share is needed to facilitate this operation. On the bastion server create a directory and share it so that it can hold a database backup from the primary SQL server and restored to secondary SQL server. The directory and the share must be accessible by the SQL Service account as the backup is performed by the service account for the database.



1. On the bastion host, open a PowerShell session.

$domainnb = "<NB_Domain>"
$user = $domainnb + "sqlsvc"
New-Item -Path "C:" -Name "TempShare" -ItemType "directory"
$ACL=Get-ACL -Path "C:TempShare"
$AccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule($user,"FullControl","Allow")