Chatta subito con l'assistenza
Chat con il supporto

NetVault Plug-in for SQL Server 14.0 - User Guide

Introducing NetVault Plug-in for SQL Server Planning your SQL Server deployment Installing and removing the plug-in Configuring the plug-in Backing up data
Defining a backup strategy Understanding snapshot-based backups Reviewing the compression features Performing Online VDI backups Performing VSS backups in SQL Server Example of creating a full VDI backup of an AlwaysOn Availability Group on Windows Removing a SQL Server Instance
Restoring data Using the CLI with the plug-in Troubleshooting

Limitations for our current support of IP-less and no-CNO AAG

The end user will have to create a virtual client using a fixed ip address of one of the real clients. This is a limitation because if the node is down, backups will fail.

If a failover occurs for some reason (rebooting for updates for example and a different node becomes active) even though all nodes in the AAG are up, the job fails.The node whose IP was given during the creation of the virtual client must be the active node.

Plug-in for SQL Server supports clusterless, read-scale SQL Server AlwaysOn Availability Groups (AG). Traditional SQL Server AlwaysOn Availability Groups are associated with Windows Server Failover Clustering (WSFC), using the layer of services provided by WSFC. For example, virtual IP addresses and automatic failover. However, starting with SQL Server 2017, it is possible to configure AGs without a traditional cluster. They are referred to as clusterless, read-scale, or IP-less AG.

AlwaysOn Availability Groups with WSFC

•
AlwaysOn Availability Groups (AGs) rely on WSFC for features. For example, automatic failover, virtual IP addresses, quorum management, and heartbeat detection.
•
WSFC provides shared storage and a central coordination point for the AG replicas.
•
AlwaysOn Availability Groups are WSFC, are ideal for High Availability and Disaster Recovery (HADR) scenarios.

Clusterless, Read-Scale, IP-less AlwaysOn Availability Group

•
SQL Server 2017 introduced the ability to configure AGs without a WSFC.
•
Clusterless AGs are typically used in environments that require high volume of data retrieval capabilities (read-scale) or environments where WSFC deployment is not feasible.
•
Clusterless AGs do not have automated failover capabilities. Therefore failover requires manual intervention, resulting in prolonged downtimes.
•
Clusterless AGs are an option for read-only replicas or disaster recovery scenarios where manual intervention is acceptable.
* 
NOTE: When using Clusterless AGs, it is necessary to manually manage connection strings and monitor possible data inconsistencies, after a failover occurs.
•
When running Clusterless AGs, it will be necessary to manually manage the failover process, which includes stopping transactions on the primary copy, verifying synchronization, and then failing over to the secondary copy.

 

* 
IMPORTANT: To support Clusterless, read-scale, IP less Plug‑in for SQL Server AG that does not use a cluster name object (CNO) or a failover IP address, create a NetVault Backup Virtual Client that uses a fixed IP address or network name that corresponds to one of the Real Clients in the AG. If the machine to which the fixed IP address or network name corresponds, for any reason goes offline, then subsequent backup jobs fail. Either bring the machine back online or update the NetVault Virtual Client to use a different IP address or network name, of one of NetVault Real Clients in the AG, that is online.

NetVault Policy Management

A NetVault Job Policy can be used to submit one or more jobs that target one or more similar clients.

If you intend to use NetVault Job Policy across your organization's SQL Server clients, Quest strongly recommends that you use, whenever possible, a generic name for the SQL Server Instances deployed in different SQL Servers. Do not use a name associated with the machine on which the instance resides, or a name that is unique.

Jobs generated for instances with unique names, in general, cannot be ported to other SQL Server clients in your organization. Using generic instance names improves portability and policy management across all affected clients. In this way, you can create NetVault Job Policies that can be applied to the different SQL Server clients in your organization.

For more information, see the Managing Policies in the Quest NetVault Administrator’s Guide.

 

Related Documents

The document was helpful.

Seleziona valutazione

I easily found the information I needed.

Seleziona valutazione