Lesson Learned #157: Connecting to Azure Managed Instance Using Oracle Database Gateway for ODBC

by Contributed | Jan 20, 2021 | Technology

This article is contributed. See the original author and article here.

Today, we received a new service request that our customer wants to connect from Oracle to Azure SQL Managed Instance or Azure SQL Database using Oracle Database Gateway for ODBC using a Windows Operating system.

Following, I would like to share with you the steps that we’ve done:

First Step: Installation and Configuration of the different components:

1) Oracle Database Gateway for ODBC

• Install it defining a new listener using the port, for example, 1528.


• I modified the listerner.ora adding the following text:

SID_LIST_LISTENER_ODBC =
  (SID_LIST =
    (SID_DESC=
       (SID_NAME=dg4odbc)
       (ORACLE_HOME=C:apptgusernameproduct19.0.0tghome_2)
       (PROGRAM=dg4odbc)
    )
  )

• The final result of listener.ora file looks like:

# listener.ora Network Configuration File: C:apptgusernameproduct19.0.0tghome_2NETWORKADMINlistener.ora
# Generated by Oracle configuration tools.

LISTENER_ODBC =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1528))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1528))
    )
  )

SID_LIST_LISTENER_ODBC =
  (SID_LIST =
    (SID_DESC=
       (SID_NAME=dg4odbc)
       (ORACLE_HOME=C:apptgusernameproduct19.0.0tghome_2)
       (PROGRAM=dg4odbc)
    )
  )

• I restarted the listener for this specific Oracle Instance. 

2) I modified the tnsnames.ora adding the following text: 

dg4odbc =
  (DESCRIPTION=
    (ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1528))
    (CONNECT_DATA=(SID=dg4odbc))
    (HS=OK)
  ) 

3) I re-started the listener.

4) I modified the file placed on <oracle_home_folder>admin subfolder on your Oracle Home Installation with the following parameters:

# This is a sample agent init file that contains the HS parameters that are
# needed for the Database Gateway for ODBC

#
# HS init parameters
#
HS_FDS_CONNECT_INFO = dg4odbc
HS_FDS_TRACE_LEVEL = OFF


#
# Environment variables required for the non-Oracle system
#
#set <envvar>=<value>

5) The parameter of the previous file HS_FDS_CONNECT_INFO contains the name of the Data Source Name that we are going to use to connect. So, in this situation, using ODBC Data Source Administrator (64-Bit) I defined the following data source parameters:

• Name: dg4odbc


• Server: The name of my public instance name

• SQL Server Authentication. 

• Database Name that I want to connect.

Second Step: Test the connectivity and run a sample query.

• Open a new Windows Command Prompt, I run sqlplus to connect to any instance of Oracle that I have: sqlplus system/MyPassword!@OracleInstance as sysdba


• I created a database link to connect using ODBC to my Azure SQL Managed Instance

create database link my4 connect to "myuserName" identified by "MyPassword!" using 'dg4odbc';

• Finally, I executed the following query to obtain data from the table customers making a reference of this database link: 

select * from customers@my4;

As I mentioned before this configuration process works, also, connecting to Azure SQL Database.

Enjoy!

Security Control: Enable audit and logging

by Contributed | Jan 20, 2021 | Technology

This article is contributed. See the original author and article here.

As part of our recent Azure Security Center (ASC) Blog Series, we are diving into the different controls within ASC’s Secure Score.  In this post we will be discussing the control of Enable audit and logging.

Log collection is a relevant input when analyzing a security incident, business concern or even a suspicious security event. It can be helpful to create baselines and to better understand behaviors, tendencies, and more.

The security control enable auditing and logging, contains recommendations that will remind you to enable logging for all Azure services supported by Azure Security Center and resources in other cloud providers, such as AWS and GCP (currently in preview). Upon the remediation of all these recommendations, you will gain a 1% increase in your Secure Score.

Recommendations

The number of recommendations will vary according to the available resources in your subscription. This blog post will focus on some recommendations for SQL Server, IoT Hub, Service Bus, Event Hub, Logic App, VM Scale Set, Key Vault, AWS and GCP.

Auditing on SQL Server should be enabled

Enable auditing is suggested to track database activities. To remediate, ASC has a Quick Fix button that will change the Microsoft.Sql/servers/auditingSettings property state to Enabled. The logic app will request the retention days and the storage account where the audit will be saved. The storage account can be created during that process, the template is in this article. Nonetheless, there is also a manual remediation described in the Remediation Steps.  The recommendation can be Enforced, so that Azure policy’s DeployIfNotExist automatically remediates non-compliant resources upon creation. More information about Enforce/Deny can be found here.  To learn more about auditing capabilities in SQL, read this article.

Diagnostic logs in IoT Hub should be enabled

This enables you to recreate activity trails for investigation purposes when a security incident occurs or your IOT Hub is compromised. The recommendation can be Enforced and it also comes with a Quick Fix where a Logic App modifies the Microsoft.Devices/IotHubs/providers/diagnosticSettings Metrics AllMetrics and the Logs Connections, DeviceTelemetry, C2DCommands, DeviceIdentityOperations, FileUploadOperations, Routes, D2CTwinOperations, C2DTwinOperations, TwinQueries, JobsOperations, DirectMethods, DistributedTracing, Configurations, DeviceStreams to “enabled”: true. To learn more about Monitoring Azure IoT Hub visit this article.

Diagnostic logs in Service Bus should be enabled

This recommendation can be Enforced, and it has a Quick Fix that will remediate the selected resources by modifying Microsoft.ServiceBus/namespaces/providers/diagnosticSettings “All Metrics” and “OperationalLogs” to “enabled”: true. It is necessary to put the retention days to deploy the Logic App. To manually remediate it, follow this article.  To learn more about the Service Bus security baseline, read this article.

Diagnostic logs in Event Hub should be enabled

The Quick Fix has a Logic App that will modify for selected resources the Microsoft.EventHub/namespaces/providers/diagnosticSettings metrics AllMetrics and the logs ArchiveLogs, OperationalLogs, AutoScaleLogs to “enabled”: true, with the retention days input. This recommendation can be Enforced. For manual remediation steps, visit this article. To learn more about the Event Hub security baseline, read this article.

Diagnostic logs in Logic Apps should be enabled

The recommendation can be Enforced and it comes with a Quick Fix where a Logic App modifies the Microsoft.Logic/workflows/providers/diagnosticSettings metrics “AllMetrics” and logs “WorkflowRuntime” to “enabled”: true. The retention days field has to be input at the beginning of the remediation. For manual remediation steps, visit this article. To learn more about Logic Apps monitoring in ASC, read this article.

Diagnostic logs in Virtual Machine Scale Sets should be enabled

This specific recommendation does not come with the Enforce feature nor a Quick Fix. To configure the Azure Virtual Machine Scale Set diagnostics extension follow this document. The command az vmss diagnostics set will enable diagnostics on a VMSS. To learn more about the Azure security baseline for Virtual Machine Scale Sets, read this article.

Diagnostic logs in Key Vault should be enabled

The recommendation can be Enforced and it also comes with a Quick Fix where the Logic App goes to the resource Microsoft.KeyVault/vaults/providers/diagnosticSettings and sets the metrics AllMetrics and logs AuditEvent to “enabled”: true including the retention days input. For manual remediation steps, read this article. To learn more about monitoring and alerting in Azure Key Vault, visit this article.

Ensure a log metric filter and alarm exist for security group changes – AWS Preview

By directing CloudTrail Logs to CloudWatch Logs real-time monitoring of API calls can be achieved. Metric filter and alarm should be established for changes to Security Groups. Recommendations for AWS resources do not have the Enforce feature, Quick Fix button, Trigger Logic App. To remediate them, follow the AWS Security Hub documentation.

Ensure that Cloud Audit Logging is configured properly across all services and all users from a project – GCP Preview

Ensure that Cloud Audit Logging is configured to track read and write activities across all supported services and for all users. Configured this way, all administrative activities, or attempts to access user data, will be tracked. Recommendations for GCP resources do not have the Enforce feature, Quick Fix button, Trigger Logic App. To remediate them, follow the Manual Remediation Steps. For more information, visit the GCP documentation.

Reviewer

Yuri Diogenes, Principal Program Manager (@Yuri Diogenes)

Oracle Storage Snapshots with Azure Backup

by Contributed | Jan 20, 2021 | Technology

This article is contributed. See the original author and article here.

One of the biggest challenges to IO demands on an Oracle on Azure VM is when customers continue to utilize streaming backup technology like RMAN or import/exports via DataPump in the cloud.  Although it shouldn’t come as a surprise, these two technologies can often be the biggest consumers of IO-  more than overall  batch or transactional processing.

One of the reasons customers migrate to the cloud is the benefit to share infrastructure resources and features at a lower cost, but with sharing those resources, no one wants to be the noisy neighbor.  Azure, as with other cloud providers, ensures that a VM can’t be the noisy neighbor by spreading workloads for a VM across hardware and setting limits per VM series and size. 

Heavy Cost of Archaic Backups

With this understanding, it is important to know that backups, both physical and logical, can be the main contributor to IO throttling on a VM.  When this occurs, the workload has hit the threshold for how much IO is allowed, either for storage or network and latency occurs.  One of the best ways to avoid this is to rethink how we backup up Oracle VMs in the cloud.

Snapshots can be a powerful tool and many organizations have already embraced this technology, but if you have not, there are definite benefits:

1. Extensively less IO requirements to take a storage level snapshot.


2. Faster Recovery times.


3. Simpler cloning process for databases and multi-tier environments.


4. A cost-effective backup solution since storage snapshots are inherently incremental.

Azure Backup Snapshots for Oracle

This brings me to Azure Backups private preview for Oracle snapshots.  For those customers who want a single pane of glass for their backups, you can now use the same Azure backup for your Oracle databases running on IaaS VMs just as you do for other Azure cloud services. 

Azure Backup for Oracle works with Oracle, setting the environment, quiescing the database, taking a snapshot and then releasing the database, to then complete the rest of its work behind the scenes.  The workflow for the backup pre-script/snapshot/post-script is as follows:

Snapshots can be configured on a daily basis or more often, but recognize that while the volume is restored to the time of the snapshot, the database remains in a recovery state and can be rolled forward using the RECOVER AUTOMATIC DATABASE with archive logs to any point in time to eliminate data loss.  If just using the snapshot to refresh a development or test environment, a snapshot recovery can be done in a matter of minutes to the time of the snapshot, refreshing data without the extensive time or work that is required with more traditional methods of cloning.

Of course, this will require archive logs be copied with a custom solution to be used to recover if a Point in Time, (PiT) recovery is desired.  I haven’t met a DBA yet who doesn’t have a shell script or other process to copy their archive logs to secondary storage to protect these valuable assets and with Azure snapshots for Oracle, this should be an additional step for anyone wanting to do more than just recover from a snapshot of a volume.  Most customers, depending on the amount and size of archive logs, choose to copy to blob, NFS or AFS.  Without this secondary step, only the archive logs that existed at the time of the snapshot locally will exist for recovery purposes.

Options for Data Refreshes

For customers that have used Oracle Datapump for data refreshes, this often required a full export of the database performed on a regular basis, consuming significant resources on a cloud VM.  With an Azure backup snapshot of the storage, a clone can be created and using this clone, an object copy can be performed instead of standard datapump export/import.  This can also be used to perform a transportable tablespace import without the resource demands to preemptively export data every night from the database, freeing up resources for batch and transaction processing.

With this shift, there is less worry about having to scale up a VM unless its for right reasons-  like due to data acquisition or business and revenue increase.  Costs are decreased on the storage side that were once used by physical datafile copies in exchange for snapshots, which on average use considerably less storage space.  When focusing on Oracle, backup storage can be important as these databases are often some of the largest in the relational database world.

If you’d like to learn more about using Azure Backup to take snapshots of Oracle workloads on Azure, check out the following link.

Simple Azure Managed Application: creating, testing, and publishing in Partner Center

by Contributed | Jan 20, 2021 | Technology

This article is contributed. See the original author and article here.

In the following two videos, we look at how to create and test a simple “Hello World”-style Azure Managed Application in the developer’s Azure subscription, and how to publish the same application in the Partner Center and deploy its “preview” in an end-customer Azure subscription under a different Azure Active Directory tenant.

In subsequent videos, we may go deeper and look at Azure Managed Application that includes an AKS resource, managed identities, deployment-time role assignments, etc.

You can see the sample code used in the videos below here.

Important: When building your Azure Application ARM templates for submission to Azure Marketplace, please make sure to carefully follow all of the guidelines and best practices described here and be ready to make fixes and changes based on manual review feedback.

Video #1: Creating and testing a simple Azure Managed Application in the developer’s Azure subscription

Tip: Play the video full screen to see all of the details.

Video #2: Publishing Azure Managed App in Partner Center and testing in end-customer’s Azure subscription

Tip: Play the video full screen to see all of the details.

Dive Deeper

If you want to dive deeper into an experimental scenario, see related article “Azure Managed Application with AKS and deployment-time or cross-tenant role assignments to VM and Pod Managed Identities”.

Originally published at https://arsenvlad.medium.com/simple-azure-managed-application-creating-testing-and-publishing-in-partner-center-d2cb3b98bed2 on September 15, 2020.

Architectural Decisions to maximize ANF investment in HANA N+M Scale-Out Architecture – Part 1

by Contributed | Jan 20, 2021 | Technology

This article is contributed. See the original author and article here.

Introduction

Do you have a large performance-sensitive SAP HANA footprint in Microsoft Azure? Are you looking to leverage SAP’s native resilience solution? Is operational flexibility at the top of your mind? If so, then look no further. This blog covers and answers the above-mentioned questions with Microsoft’s newer (since May 2019) PaaS storage service in partnership with NetApp, called Azure NetApp Files (ANF). While providing bare-metal performance with sub-millisecond latency and unparallel operational flexibility, the service also opens the door for its customers to leverage the SAP HANA’s native high-availability feature for N+M scale-out architecture, called ‘host auto-failover’, thanks to NFS v4.1 support on ANF.   

In this blog series, I will focus on the technical execution aspects of running SAP HANA scale-out N+M on Azure NetApp Files from a Solution Architect’s point-of-view. More specifically, I will focus on how a solution architect would design, build, and operate the infrastructure, backup/recovery, and HA/DR components for a 2+1 scale-out scenario running on RHEL OS. I will not focus on the application tier, neither will I focus on other cloud foundational elements. This blog series would also pique interests of Operations Architects, Database Administrators, and the likes. This series is broken up into multiple publications to cover the journey step by step. This part, Part 1, covers the overall solution overview and the base infrastructure design and build. Part 2 will cover the backup/recover, and Part 3 will cover the HA/DR component. Let’s get to it.

Solution Overview

The key architectural components of this scenario include multiple SAP HANA nodes that are set up as one scale-out system. The required shared storage for this setup would come from Azure NetApp Files, with NFS v4.1 selected as the protocol of choice. There will be an additional virtual machine to provide a centralized automatic backup management capability utilizing a new-to-ANF tool called “azacsnap” (in preview). A pseudo diagram to capture this high-level solution would look something like this:

Pseudo Design Diagram

We will now take this initial diagram and transform it through the three phases of solution designing and building across the solution components (base infrastructure, backup and HA/DR). These phases of solution designing are:

• Assess/Plan


• Design


• Build/Operate

Note: The intention throughout the blog is to cover a solution architect view to designing and building the solution in a more thought-provoking manner, and to compliment already available well-crafted MS Docs and NetApp documentation on this topic. I will cover key highlights from these documentations, and where necessary, will also augment additional detail in this blog to cover more surface area.

Assess/Plan – Infrastructure, Backup/Recovery and HA/DR

The criticality of assessing and planning for a major technical solution cannot be overstated. While the Cloud is synonymous with flexibility, the price of remediating certain elements of the architecture, to accommodate for the requirements that fell through the crack during discovery, could be costly. Therefore, take your time in making decisions around foundational elements of SAP landing zone such as subscription design, network design, HANA scaling architecture etc. It is much harder to retrofit them especially when you have an active infrastructure. Taking time in planning and assessing goes a long way. This solution is no exception. Let’s look at some of the key points of planning:

• SAP landing zone/cloud foundation planning: The planning for the cloud foundational elements is not in scope for this blog. Let’s assume standard SAP landing zone components are already in place.


• SAP HANA architecture planning: The architecture planning for SAP HANA is also assumed to have been completed, alongside the decision to select ANF as the shared storage choice for the architecture.


• Single versus multiple subscriptions: It is important to know the high-level Disaster Recovery (DR) solution for this setup could drive the subscription requirement for the SAP landing zone planning. As of now, the ANF Cross Region Replication (CRR) only supports replication within the same subscription. If you intend to use CRR as the DR solution over SAP HANA System Replication, then you must use one subscription. ANF team brings expansion to existing features set and relaxation to existing limitations on a regular basis, so be sure to validate this at the time of planning.


• Region selection: ANF service availability, ANF CRR region pairing and SAP HANA VM SKU selection are among the key factors in deciding the regions of choice for primary operations and disaster recovery.


• Number of ANF accounts: An ANF account is an administrative layer with a regional scope that holds one or more storage pools. Creating an account per region will give you the most flexibility from system restore and environment refresh purposes. You will not be able to create a copy of an ANF volume outside its associated storage pool.


• Networking: ANF requires a delegated subnet per VNET. A /28 with 11 usable IP addresses is sufficient. Also, you cannot apply NSGs or UDRs on this subnet.


• High-Availability: The ANF service is a PaaS service and the resilience is already baked in. However, we will need high-availability for SAP HANA DB. Since we are covering the N+M scenario, the high-availability is provided by the native HA feature called Host Auto-failover. This means an additional same size HANA VM is needed as a stand-by and a distinct storage configuration to support this scenario. Also, plan on placing them in an availability set (AS) associated with a proximity placement group (PPG). Why? See the next point:


• Minimizing latency: In addition to leveraging PPG/AS to bring App and DB closer, we will also use PPG/AS to manually pin the ANF resources closer to HANA Databases. This is a manual backend process and needs to be coordinated with Microsoft support team.


• Backup Offloading: Will you be using ANF snapshots for HANA backups? If so, do you have a requirement to provide additional redundancy and protection to ANF snapshots? This is surely not a must due to already available redundancy in ANF and the security layers you could leverage at VNET, AAD/RBAC and OS levels etc. However, should you have such a requirement, you will need to invest in a secure storage account for offloading backups and for keeping redundant full copies.


• Security: For this scenario, the recommendation is to use NFS v4.1 as the protocol for all SAP HANA volumes. Besides the restriction on the delegated subnet, your VNET overall can have the desired enterprise-scale security protocols. You can also apply all the recommended OS-level security for Linux as well as application-level security for the HANA DB. You can control the access to the ANF PaaS service via RBAC. Keep in mind that if you are planning to automate scheduling of the database snapshots, we will need to allow outbound access to publicly available Azure APIs. This is needed for the automation and orchestration software, azacsnap, to be able to access Azure AD via a service principal to interact with the ANF service.


• ANF Storage Capacity Planning: We will need the sizing estimate for SAP HANA DB. In addition, a high-level backup policy (backup scope, frequency, retention) and offloading/offsite requirements is also required. Finally, we will need to leverage the different performance tiers – ultra, premium, and standard to balance the cost and performance need for each of the volumes.


• Available ANF Features: ANF product team has a great customer feedback cycle, and as a result, the ANF service is refreshed regularly with feedback-resulted features. Be sure to check what’s new in ANF world and assess whether you would like to add any of the latest and greatest feature to your design.

Next, we will take this assessment and the key findings into the design phase. We will design the base infrastructure first, and then will design the backup/restore and HA/DR components on top of it.

Design – Base Infrastructure

Network

• This design includes a single VNET for both Prod and Non-Prod. However, the other options include:
  
  
  
  • You could have created two or more VNETs for segregation with each VNET to have volumes associated with a separate ANF account, but that would restrict the environment refresh across VNETs.
  
  
  • Another option would be to place ANF volumes in one VNET and provision them to clients in all the peered VNETs. Account for minor to negligible latency here due to peering. Also keep in mind the transit routing restriction with the VNET peering.
  
  
  • A slight variation to the above, you could create an ANF delegated subnet per VNET, create volumes in each of the subnets and provision the volumes to the clients in the respective VNETs. It is still all under the same ANF account.
  
  
  
  


• Each VNET receiving the ANF volumes must have one and only one delegated subnet dedicated for ANF. If you try to deploy to another delegated ANF subnet within the same VNET, you will get an error like this:

• A delegated subnet /28 delegated is sufficient for most cases. For a very large deployment, say 12+ scale-out nodes running on very large Mv2s, you may need a bigger subnet to maximize performance with concurrent unique network paths to ANF.


• The management VM will need an SPN authentication using Azure public APIs. You will need an outbound access to azure APIs as stated.


• Attach three NICs per HANA node for segregating the client, inter-node and ANF storage communications. This will not triple the network performance on the VM.

Compute

• Two HANA Scale-out nodes plus the stand-by node in the DB or equivalent subnet. You can increase the count per your requirement. The VM SKUs, chosen to meet the HANA sizing requirement, must be supported by SAP. Check out the SAP Note 1928533 for more information.


• Associate HANA DB VMs with an availability set tied to a PPG.


• A Backup Management VM in a separate subnet for isolation. A D2s/D4s would do just fine. Also, we don’t need a data disk on this VM for this scenario.

Storage – Azure NetApp Files

• An ANF Account per region: A single account in the region will streamline the environment refresh for lower environments in the region.


• An Ultra storage pool and a premium storage pool: The Ultra pool would hold hana data and log volumes, while the premium would hold the rest. If you are concerned about reaching the 500TB maximum size limit of the pool, then create a pair of Ultra and Premium pools for each of the SAP landscapes. For example:

BW: Pool 1: Ultra Pool , Pool 2: Premium Pool

CAR: Pool 3: Ultra Pool, Pool 4: Premium Pool

And so on

This setup would enable both the needed scalability and the ability to perform lower environment system refreshes.

• Volume size as a function of HANA memory: Follow the typical sizing approach for SAP HANA but stay above the minimum size as mentioned below to stay to meet the minimum performance guidelines. The details are in MS Docs – HANA storage configurations with ANF

As an example, the volume sizes for 2+1 M128s (2TB) would look like this:

*Note:

1. I encourage to perform benchmark tests to validate the experienced throughput at the OS layer and adjust the volume throughput accordingly per the application’s requirement.


2. Due to the throughput restriction of 1.2 – 1.4 GB/s for a LIF in a single TCP session, the throughput experienced at the OS layer hits the ceiling around 15 TB for a Ultra SKU volume and 40 TB for a Premium SKU Volume. Consider using a lower tier in this situation.


3. The flexibility of dynamically changing the service level enables you to switch these volumes from one tier to another. Changes in size requirement or performance could result in exercising this option.


4. You could choose NFS v3 for volumes other than data and log, but we will keep v4.1 in this scenario for consistency.


5. OS Managed Disk: We will use premium managed for the OS disk. There is no additional data disk requirement for this scenario.

Build – Base infrastructure

The steps to build a similar architecture is well laid out in MS Docs, therefore I will not repeat them here. With this MS Doc guide, the details in the design section and the below anecdotal comments, you have enough ammunition for the build phase:

Network

• The delegated subnet is needed when we are ready to create the volumes.


• On a restrictive subnet, the outbound internet access to management URLs can be achieved by configuring an outbound rule on a dedicated public load balancer, or by configuring the outbound connectivity in Azure Firewall or in a third-party firewall.

Compute

• The anchor VM, usually the DB VM, goes first in the deployment to pin the infrastructure.


• You may run into a problem when mounting an azure storage files onto the RHEL Linux system and get an error like this:

Install cifs-utils program “yum install cifs-utils” and then try again.

• When installing SAP HANA, you may face installation errors pointing to missing modules, if so then install the following and try again: yum install libtool-ltdl

Storage

• For complex workloads, to ensure sub millisecond latency to the storage, you may need Microsoft’s assistance in performing a backend manual pinning for the ANF storage to be laid out closer to the compute units. To do that, the key information you will need to provide to the support team would be the empty Availability Set, PPG and the empty storage pool. Once the pinning is done, you are good to proceed with the infrastructure provisioning.


• For large VMs in a scale-out, depending on the environment size, performance requirement and the environment priority, you may also need to use a dedicate logical network interfaces (LIF) for each of the data and log volumes. This is also done manually today and with the help of the support team. For this 2+1 scale-out scenario, an example LIFS pinning would look like this:

IP1 à data mnt 1, IP2 à log mnt 1

IP2 à data mnt 2, IP1 à log mnt 2

This helps enabling two unique paths from each of the nodes down to the ANF volume.

Conclusion and What’s next

This concludes the first part of the blog series. Now that we have the base infrastructure, we will focus on backup/recover and HA/DR in the upcoming parts of this series. Stay tuned.

Reference