This Collector version includes the new features and updates from Collector version 4.1.
For more information, see the Collector 4.1 Release Notes.
Resolved Issues
The following issue is resolved in this release:
Improved the code-signing of bits to avoid antivirus software identifying Nutanix
Collector as a malicious software.
Open Source Software In This Release
For more information about Collector open source licensing details, see Open Source Licenses for Collector.
Stay Ahead in Today’s Competitive Market!
Unlock your company’s full potential with a Virtual Delivery Center (VDC). Gain specialized expertise, drive
seamless operations, and scale effortlessly for long-term success.
Following are the feature updates made in this release:
Performance Improvements
The data collection and output generation for Prism, vCenter, Hyper-V clusters,
hosts, and VMs, and ONTAP CIFS shares is improved by 2x to 3x.
The progress bar of the data collection for Prism, vCenter, and Hyper-V VMs
provides more granular and better information on the progress being made.
Rerunning data collection from different datacenters or clusters registered with
the same vCenter, Prism, and ONTAP CIFS shares instances are faster due to
caching.
Prism, Hyper-V, and v-Center - New column added in vPartition tab
A new column
Collector vPartition UUID
is added in the
vPartition tab to account only unique entry for calculating the storage capacity and
consumed storage.
Improved Logs Collection for Troubleshooting
For the Nutanix Collector desktop application, you can configure the log levels
such as info, debug, error, critical, and warning based on the logs you want to
collect for troubleshooting.
A new file
collector-client.log
has been added in the Nutanix
Collector bundle to collect the logs for troubleshooting.
Configure Port Number
If the listener port's default port number is in use, you can configure the port that
is unused to establish a connection.
Resolved Issues
The following issues are resolved in this release:
Fixed the instances for which the VM Summary value appeared as NaN in the output
collection file.
For Prism, the storage capacity is now captured for the volume groups that are
associated with File Server VMs.
For vHosts, fixed the 95th percentile value of the IOPS, number of read, and number of
write operations that appeared empty in the output collection file.
The VM level provisioned and consumed storage now accounts only unique partitions.
Nutanix Collector supports data collection from the servers that has more number of VMs
due to performance enhancements.
Data collection failure due to the unsupported delimiter formats is resolved.
Known Issues
This section describes the issues found in this or recent releases that you might
encounter:
In case of vPartition entries, the datastores are not considered.
Collector fails to gather the information when there is only one Prism Element cluster
under the Prism Central.
For the workaround, see the section Troubleshooting of the
Collector User
Guide
.
Open Source Software In This Release
For more information about Collector open source licensing details, see Open Source Licenses for Collector.
Important:
Data created with an early access (EA) version of Data Lens will be removed with the completion of the EA program. The data will not be available in
the general availability (GA) versions.
Nutanix Data Lens™ (Data Lens) provides a cloud-hosted analytics and
monitoring service for all of your file servers hosted on Nutanix Files. Data Lens
centralizes data from all of your clusters connected to Pulse, across various data center
locations. Cloud resources reduce scaling constraints, as the Cloud is not dependent on the
file server resources, letting you have near-real-time analytics and alerts even for
load-heavy file servers of more than 250 million files and over 500 TB of storage. Hosting
File Analytics on premises limits the service to local file servers only. In contrast, Data
Lens functions on a global level, in a cluster-neutral environment, without being tied to a
single Nutanix cluster.
Requirements
Meet the requirements for running Data Lens.
Configure a MyNutanix account to access the Data Lens console.
In Prism, enable Pulse health monitoring. See "Pulse Health Monitoring" in the
Prism Central Guide
.
Getting Started With Data Lens
Perform the tasks described in this chapter to get started with
Data Lens
.
Do the following:
Ensure that you have registered for Data Lens from the My Nutanix portal, see, Creating a My Nutanix Account.
Launch
Data Lens
, see Onboarding into Data Lens. The first admin to launch
Data Lens
becomes the account admin and
can
invite other users that are associated with the account ID.
Enable
Data Lens
for Nutanix Files file servers, see
Data Lens Global Dashboard. You can monitor the enablement in
the Tasks view.
Creating a My Nutanix Account
You must have a My Nutanix Account to access the Data Lens
console.
About this task
Perform the following procedure to create a My Nutanix account.
Procedure
In the address bar of a web browser, type
https://my.nutanix.com
and click
Enter
.
Click
Sign up now
.
Enter the details such as
First Name, Last Name, Company name, Job
title, Phone number, Country, Email,
and
Password
.
Follow the specified password complexity requirements when you are creating
the password.
Click
Submit
.
A confirmation page is displayed and you receive an email from
mynutanix@nutanix.com after you successfully complete the sign-up
process.
Following is an example of the email.
Hi First Name,
Welcome to the My Nutanix portal!
To get started, confirm your email by clicking on the link below. If clicking the link does not work, you can copy and paste the link into your browser's address window.
https://my.nutanix.com/#/verify?username=your_email_address_ &confirmation=
If you run into any issues, please email portal-accounts@nutanix.com to speak with a Nutanix Portal representative. Please do not reply to this email directly.
Best Regards,
Nutanix Team
Click the link in the email to verify your email address.
A confirmation message briefly appears and you are directed to the Nutanix
Support portal.
Log on to the portal by using the credentials you specified during the sign-up
process.
The Welcome Back page appears.
Click
My Nutanix
to go to the My Nutanix
dashboard.
Onboarding into Data Lens
Before you
sign
up for a paid plan to use
Data Lens
, you can start a
60-day
free trial. To continue to use
Data Lens
after the
trial period ends, you must upgrade your plan to one of the paid plans.
About this task
Perform the following procedure to subscribe to a free trial of
Data Lens
.
Procedure
Log on to https://my.nutanix.com by using your My Nutanix credentials.
On the My Nutanix dashboard, scroll down to Cloud Services, and under
Data Lens
,
click
Get Started
. Subsequent users click
Launch
.
The
Global Dashboard
appears displaying the file
servers and object stores associated with your account.
Tip:
If you do not see the
Global
Dashboard
, enable Pulse Health Monitoring. See "Pulse Health
Monitoring" in the
Prism Central Guide
Port Requirements
The Port Reference provides detailed port information
for Data Lens and other Nutanix products and services, including port sources and
destinations, service descriptions, directionality, and protocol requirements.
Unsupported Features
Lists the unsupported features for Data Lens.
Data Lens does not support cloned file server.
Data Lens Global Dashboard
The
Global Dashboard
details all registered file
servers.
Global Dashboard View
The Data Lens
Global Dashboard
is the landing page after launching
Data Lens. The
Global Dashboard
includes a table that lists all file
servers across all of your registered clusters.
Figure.
Data Lens Global Dashboard
Click to enlarge
The
Global Dashboard
consists of the following elements.
An
Anomaly Status
pane summarizes the number of file servers with
anomaly alerts, no anomaly alerts, and no rules configured.
A
Capacity and Shares
pane summarizes the total number of shares
and total capacity analyzed on all file servers with Data Lens enabled (excluding
snapshots). You can view the details of the shares of a particular file server by clicking
the link on the total number of shares. (See "Share Details View" below). Total capacity
analyzed is calculated and updated every hour.
A
Data Summary
pane summarizes the number of users, directories,
and files across all file servers with Data Lens enabled.
A
File Server
pane displays region-wise file servers. Clicking
the table icon in the top right corner switches to a
List of File
Servers
, see the "List of File Servers Table" for details.
Note:
File
servers do not appear for clusters with Pulse Health Monitoring disabled.
Table 1.
List of File Servers
Column
Description
Status
Indicates if Data Lens is enabled or disabled.
Vendor
Indicates the file server vendor.
File Server Name
Indicates the name of the file server.
Number of Shares
Indicates the number of shares and exports on the file server.
File Server Version
Indicates the Files version of the file server.
Data Retention
Indicates the data retention period of Data Lens
data.
Three-Dot Menu
Provides options to enable or disable Data Lens on the file
server.
Share Details View
In the
Data Summary
pane, clicking the number of
Shares
displays
Share Details
view.
Figure.
Share Details
Click to enlarge
The
Share Details
view consists of the following elements.
A
File Server drop-down
lets you select a file server of the
logged in account. Based on the selected file server, the total capacity, current usage,
and the share details appear in the table.
Total Capacity
indicates the total capacity for the file
server.
Current Usage on Primary (includes system files)
indicates the
current usage of the file server.
Note:
Tiered data is excluded for calculating the
current usage.
The
List of Shares
lists all of the shares on the selected file
server, including all active shares and deleted shares for which Data Lens retains audit
data. The list is ordered by the highest percentage of used and max capacity of the share.
See the "Shares Table" for details.
Note:
Data Lens updates used capacity for shares on an hourly basis, not in
real-time.
The list does not include nested shares (active or deleted).
The list does not include deleted shares for which Data Lens does not retain audit
data.
Table 2.
Shares Table
Column
Description
Share Name
Indicates the name of the share.
File Server
Displays the name of the file server of that share.
Used Capacity
Indicates the capacity used by the share.
Max Size
Indicates the quota assigned to a share, and it is the max capacity a share can
use.
If value of max size is not defined,
Undefined
value is
displayed in the table.
Dashboard
The
Dashboard
tab displays data on the operational trends of an
entity (file server, object, or share).
Dashboard View
The
Dashboard
tab is the opening screen that appears after launching
Data Lens for a specific entity. The
scope selector
indicates the
entity for which the dashboard displays data using various widgets. By default the
scope selector
displays data for the file server (all shares). To
have the widgets display data for a specific, select a single share from the
scope selector
. See the "Dashboard Widgets" table for a description
of each widget.
Note:
Widgets refresh hourly.
Figure.
Data Lens Dashboard
Click to enlarge
Table 1.
Dashboard Widgets
Tile Name
Description
Values and Intervals
Data Growth Trend
Displays data growth trends for the entity including the data added, data
removed, and net changes.
Clicking an event period widget displays the
Data Growth Trend Details
view.
Clicking the
View Forecast
displays the data growth forecast for a time
period.
7 days, the last 30 days, or the last 1 year
Data summary by age and storage tier
Displays the percentage of data by age. Data age determines the data heat,
including: hot, warm, and cold.
Includes an option to open the
Smart
Tiering Dashboard
to configure tiering and to configure cost savings,
see Configuring Cost Savings.
To edit the heat
levels, see Configuring Data Heat Levels.
Default intervals are as follows:
Hot data – accessed within the last week.
Warm data – accessed within 2 to 4 weeks.
Cold data – accessed 4 weeks ago or later.
Permission denials
Displays users who have had excessive permission denials and the number of
denials. Clicking a user displays audit details, see Audit Trails - Users View for more.
[user id], [number of permission denials]
File distribution by size
Displays the number of files by file size. Provides trend details for top 5
files.
Less than 1 MB, 1–10 MB, 10–100 MB, 100 MB to 1 GB, greater than 1 GB)
File distribution by type
Displays the space taken up by various applications and file types. The file
extension determines the file type. See the
File types
table for more
details.
MB or GB
File distribution by type details view
Displays a trend graph of the top 5 file types. File distribution details include
file type, current space used, current number of files, and change in space for the
last 7 or 30 days.
Clicking
View Details
displays the
File Distribution by Type
view.
Daily size trend for top 5 files (GB), file type (see the "File Type" table),
current space used (GB), current number of files (numeric), change in last 7 or 30
days (GB)
Potential duplicate files
Displays a summary of potential duplicate files based on their name, size, and
extension for files larger than 1MB.
Integers for total files with duplicates and total count of duplicates. MB, GB,
or TB for total size of duplicates
Top 5 active users
Lists the users who have accessed the most files and number of operations the
user performed for the specified period. When there are more than 5 active users, the
more
link provides details on the top 50 users. Clicking the
user name displays the audit view for the user, see Audit Trails - Users View for more.
24 hours, 7 days, 1 month, or 1 year
Top 5 accessed files
Lists the 5 most frequently accessed files. Clicking
more
provides details on the top 50 files.
Clicking the file name displays the audit view
details for the file, see Audit Trails - Files View for
more.
24 hours, 7 days, 1 month, or 1 year
Files operations
Displays the distribution of operation types for the specified period, including
a count for each operation type and the total sum of all operations.
Clicking an
operation displays the
File Operation Trend
view.
24 hours, 7 days, 1 month, or 1 year
Data Growth Trend Details View
Clicking an event period in the
Data Growth Trend
widget displays
the
Data growth trend details
view for that period. The view includes
the
Share/Export
and
Category
tabs (only the
Category
tab appears when viewing the details for a share). Each
tab includes columns detailing entity details such as, Name, Net Capacity Change, Data
Added, and Data Removed.
Figure.
Data Growth Trend Details View
Click to enlarge
Table 2.
Data Growth Trend Details
Column
Description
Name
Name of share/export or category
Net capacity change
The total difference between capacity at the beginning and the end of the
specified period
Data added
Total data added for the specified period
Data removed
Total data removed for the specified period
Data Growth Forecast View
Clicking the
View Forecast
for the
Data Growth
Trend
widget displays the data forecast for an entity over a time period.
The data forecast is based on the historical data of the last 90 days. From the drop-down
option, select a forecast period of 3 months, 6 months, 9 months, or 1 year.
Figure.
Data Growth Forecast Details
Click to enlarge
Table 3.
Capacity Runway Details
Usage
Description
Low Usage
The number of days in which the entity reaches the maximum capacity as per the
low usage.
Medium Usage
The number of days in which the entity reaches the maximum capacity as per
medium usage.
High Usage
The number of days in which the entity reaches the maximum capacity as per high
usage.
File Distribution by Type Details View
Clicking
View Details
for the
File Distribution by
Type
widget displays granular details of file distribution, see the
File Types
table for details.
Figure.
File Distribution by Type
Click to enlarge
Table 4.
Details of File Distribution Parameters
Column
Description
File type
Name of file type
Current space used
Space capacity occupied by the file type
Current number of files
Number of files for the file type
Change (in last 30 days)
The increase in capacity over a 30-day period for the specified file type
Clicking
View Duplicates
displays the
Potential Duplicate
Files
view. The following table describes the information found on each pane
in the view.
Figure.
Potential Duplicates View
Click to enlarge
Table 6.
Potential Duplicate Files
Pane
Summary
Overall Summary
Provides three high level metrics:
Total Files with
Duplicates
,
Total Count of Duplicates
, and
Total Size of Duplicates
.
Files With Duplicates
Includes an option to search by file name and a table that lists potential
duplicate files. The table is organized with the file names, a link to
View All Instances
, and the following columns:
original creation date
,
duplicate
count
,
size of duplicates
, and
number of duplicate file owners
.
Clicking
View All Instances
displays a table with
information about the file organized by the following columns:
Path
,
Owner
,
Share
,
Date Created
, and
Date Modified
.
Filters
Lets you filter by
original creation date
,
duplicate count
,
size of duplicates
,
number of duplicate file owners
,
data
type
,
owners
and
shares
.
File Operation Trend View
Clicking an operation type in the
File Operations
widget displays
the
File Operation Trend
view. The
File Operation
Trend
view breaks down the specified period into smaller intervals, and
displays the number of occurrences of the operation during each interval.
Figure.
Operation Trend
Click to enlarge
Table 7.
File Operation Trend View Parameters
Element
Description
Operation type
A drop-down option to specify the operation type. See
Files
Operations
in the
Dashboard Widgets
table for a list of
operation types.
Last (time period)
A drop-down option to specify the period for the file operation trend.
File operation trend graph
The x-axis displays shorter intervals for the specified period. The y-axis
displays the number of operations trend over the extent of the intervals.
Anomalies
Data panes in the
Anomalies
view display data and trends for
configured anomalies.
The
Anomalies
view provides options for creating anomaly policies
and displays dashboards for viewing anomaly trends.
You can configure anomalies for the following operations:
Creating files and directories
Deleting files and directories
Permission changes
Permission denials
Renaming files and directories
Reading files and directories
Define anomaly rules by the specifying the following conditions:
Users exceed an operation count threshold
Users exceed an operation percentage threshold
Meeting the lower operation threshold triggers an anomaly.
Consider a scenario where you have 1 thousand files, the
operation count
threshold
defined as 10, and the
operation percentage
threshold
defined as 10%. The count threshold takes precedence, as 10% of 1
thousand is 100, which is greater than the count threshold of 10.
Figure.
Anomalies Dashboard
Click to enlarge
Table 1.
Anomalies Data Pane Descriptions
Pane Name
Description
Values
Anomaly Trend
Displays the number of anomalies per day or per month.
Last 7 days, Last 30 days, Last 1 year
Top Users
Displays the users with the most anomalies and the number of anomalies per
user.
Last 7 days, Last 30 days, Last 1 year
Top Folders
Displays the folders with the most anomalies and the number of anomalies per
folder.
Last 7 days, Last 30 days, Last 1 year
Operation Anomaly Types
Displays the percentage of occurrences per anomaly type.
Last 7 days, Last 30 days, Last 1 year
Anomaly Details
Clicking an anomaly bar in the
Anomaly Trend
graph displays the
Anomaly Details
view.
Figure.
Anomaly Details View
Click to enlarge
Table 2.
Anomalies Details View Total Results Table
Column
Description
Anomaly Type
The configured anomaly type. Anomaly types not configured do not show up in the
table.
Total User Count
The number of users that have performed the operation causing the specified
anomaly during the specified time range.
Total Folder Count
The numbers of folders in which the anomaly occurred during the specified time
range.
Total Operation Count
Total number of anomalies for the specified anomaly type that occurred during
the specified time range.
Time Range
The time range for which the total user count, total folder count, and total
operation count are specified.
Indicates the entity for the operation count. Selecting the
Users
tab indicates operation count for specific users, and
selecting the
Folders
tab indicates the operation count for
specific folders.
Operation count
The total number of operations causing anomalies for the selected user or
folder during the time period for the bar in the
Anomaly
Trend
graph.
Configuring Anomaly Detection
Steps for configuring anomaly rules.
About this task
To create an anomaly rule, do the following.
Procedure
In the Data Lens web console, click the
gear icon
>
Define Anomaly Rules
.
In the
Anomaly Email Recipients
field, enter a
comma-separated list of email recipients for all anomaly alerts and data.
Note:
Data Lens sends anomaly alerts and data to recipients whenever Data Lens
detects an anomaly.
To configure a new anomaly, do the following in the indicated fields:
Events
: Select a rule for the anomaly from one
of the following:
Permission changed
Permission denied
Delete
Create
Rename
Read
The event defines the scenario type for the anomaly.
Minimum Operations %
: Enter a percentage value
for the minimum threshold.
Data Lens calculates the minimum operations percentage based on the
number of files. For example, if there are 100 files, and you set the
minimum operations percentage to 5, five operations within the scan
interval would trigger an anomaly alert.
Minimum Operation Count
: Enter a value for a
minimum operation threshold.
Data Lens triggers an anomaly alert after meeting the threshold.
User
: Choose if the anomaly rule is applicable
for
All Users
or an
Individual
user.
Type:
the type determines the interval.
The interval determines how far back Data Lens monitors the
anomaly.
Interval
: Enter a value for the detection
interval.
(optional)
Actions
: Click the
pencil
icon
to update an anomaly rule. Click the
x
icon to delete an existing rule.
Figure.
Anomaly Configuration Fields
Click to enlarge
Use audit trails to look up operation data for a specific user, file, folder, or
client.
The
Audit Trails
view includes
Files
,
Folders
,
Users
, and
Client
IP
options for specifying the audit type. Use the search bar for specifying the
entity for the audit (user, folder, file, or client IP).
The results table presents details for entities that match the search criteria. Clicking the
entity name (or client IP number) takes you to the details for the target entity.
Performing Audits
Audit a user, file, client, or folder.
About this task
Follow the steps as indicated.
Procedure
Go to
collapse menu
>
Audit Trails
.
Select the
Files
,
Folders
,
Users
, or
Client IP
option.
(optional) In the shares field, check or un-check target
shares.
Enter the audit trails target into the search bar.
Click
Search
.
To display audit results in the
Audit Trails
window,
click the entity name (or client IP number).
Audit Trails - Users View
Details for the user audit trails view.
Audit Trails Search - Users
When you search by user in
Audit Trails
, search results display the
following information in a table:
User Name
Domain
Last Operation
Last Operation On
Share Name
Operation Date
Action
Figure.
Users Search Results
Click to enlarge
Audit Details Page - Users
Clicking
View Audit
displays the
Audit
Details
page, which shows the following audit information for the selected
user.
A
User Events
graph displays various operations the user
performed during the selected period and the percentage of time each operation has
occurred per total operations during the specified period.
The
Filter by operations
dropdown contains operation filters,
which you can use to filter the audit by operation type. Operations include:
Create File
Delete
Make Directory
Permission Changed
Permission Denied
Read
Remove Directory
Rename
Set Attribute
Write
Symlink
The
filter bar
, above the User Events graph, displays the
filters in use.
Use the
From
and
To
fields to filter
by date.
The
Results
table displays operation-specific information. See
more details below.
The
Reset Filters
button removes all filters.
Figure.
User Audit Details - Events
Click to enlarge
The
Results
table provides granular details of the audit results.
The following data is displayed for every event.
User Name
User IP Address
Operation
Operation Date
Target File
Click the
gear icon
for options to download the data as an xls, csv,
or JSON file.
Figure.
Results Table
Click to enlarge
Audit Trails - Folders View
Details for the folder audit trails view.
When you search by folder name in
Audit Trails
, search results
display the following information in a table:
Folder Name
Folder Owner Name
Share Name
Parent Folder
Last Operation
Last Operation By
Last Operation Date
Action
Figure.
Folders Search Results
Click to enlarge
The
Audit Details
page shows the following audit information for the
selected folder.
A
Folder Events
graph displays various operations performed on
the file during the selected period, and the percentage of time each operation has
occurred per total operations during that period.
The
Filter by operations
dropdown contains operation filters,
which you can use to filter the audit by operation type. Operations include:
Select All
Make Directory
Permission Changed
Permission Denied
Remove Directory
Rename
Set Attribute
A
filter bar
, above the File Events graph displays the
filters in use.
Use the
From
and
to
fields to filter
by date.
The
Results
table displays operation-specific details.
The
Reset Filters
button removes all filters.
The
Results
table provides granular details of the audit results.
Data Lens
displays the following data for every event.
User Name
Client IP
Operation
Operation Date
Click the gear icon for options to download the data as a CSV file.
Audit Trails - Files View
Dashboards details for the files audit trails view.
Audit Trails for Files
When you search by file name in
Audit Trails
, search results display
the following information in a table:
File Name
File Owner Name
Share Name
Parent Folder
Last Operation
Last Operation By
Last Operation Date
Action
Figure.
Files Search Results
Click to enlarge
Note:
Data Lens
does not support regular expression (RegEx) based
search.
The
Audit Details
page shows the following audit information for the
selected file
A
File Events
graph displays various operations performed on the
file during the selected period, and the percentage of time each operation has occurred
per total operations during that period.
The
Filter by operations
dropdown contains operation filters,
which you can use to filter the audit by operation type. Operation types include:
Close File
Create File
Delete
Make Directory
Open
Read
Rename
Set Attribute
Write
Symlink
A
filter bar
, above the File Events graph displays the
filters in use.
Use the
From
and
to
fields to filter
by date.
The
Results
table displays operation-specific details.
The
Reset Filters
button removes all filters.
Figure.
Files Audit Details - Events
Click to enlarge
The
Results
table provides granular details of the audit results.
Data Lens
displays the following data for every event.
Username
Client IP
Operation
Operation Date
Click the gear icon for options to download the data as a CSV file.
Figure.
Results Table
Click to enlarge
Audit Trails - Client IP View
Details for the client IP audit trails view.
Audit Trails Search - Client IP
When you search by client IP in
Audit Trails
, search results display
the following information in a table:
Client IP
User Name
Domain
Last Operation
Last Operation On
Share Name
Operation Date
Action
Figure.
IP Search Results
Click to enlarge
The
Audit Details
page shows the following audit information for the
selected client.
A
User Events
graph displays various operations performed on the
client during the selected period, and the percentage of time each operation has occurred
per total operations during that period.
The
Filter by operations
dropdown contains operation filters,
which you can use to filter the audit by operation type. Operation types include:
Create File
Delete
Make Directory
Permission Changed
Permission Denied
Read
Removed Directory
Rename
Set Attribute
Write
Symlink
Permission Denied (File Blocking)
A
filter bar
, above the File Events graph displays the
filters in use.
Use the
From
and
to
fields to filter
by date.
The
Results
table displays operation-specific details.
The
Reset Filters
button removes all filters.
Figure.
Files Audit Details - Events
Click to enlarge
The
Results
table provides granular details of the audit results.
Data Lens
displays the following data for every event.
User Name
Operation
Target File
Operation Date
Click the gear icon for an option to download the data as a CSV file.
Ransomware Protection
Protecting your file server against 0-day ransomware detection and
protection.
Caution:
Ransomware protection helps detect potential ransomware. Nutanix does not
recommend using the Data Lens ransomware feature as an all-encompassing
ransomware solution.
Data Lens scans file audit events for ransomware in near real time and notifies you in the
event of a ransomware attack once you configure email notifications. Ransomware protection
includes signature-based and event-pattern-based ransomware detection.
Signature Detection
Signature-based detection uses the Nutanix Files ransomware file blocking mechanism to
identify and block file renames whose extension and file names match ransomware signatures
carrying out The blocking of file renames helps to identify file malicious activity by
containing the ransomware attack from further infecting the files . The ransomware file
blocking mechanism uses a dynamically curated list of signatures that frequently appear in
ransomware files. The curated list is dynamically updated as new ransomware signatures are
available. You can also modify the list by manually adding or removing signatures.
Event Pattern Detection
Event-pattern-based ransomware protection looks for audit events in near real time to
identify potential ransomware attacks. Configuring auto-remediation allows you to block
malicious clients from accessing all shares. In addition to that customers will also have
the option to put the files in Read-Only mode where no clients will be able to do any write
operations to the shares . Customers are recommended to upgrade to Files 4.2 to use advanced
auto-remediation features as described above containing the ransomware attack from further
infecting the files.
Note:
Customers are recommended to upgrade to Files 4.2 to use advanced auto-remediation
features.
Data Lens also monitors shares for self-service restore (SSR) policies
and identifies shares that do not have SSR enabled in the ransomware dashboard. You can
enable SSR through the ransomware dashboard.
Ransomware Protection Dashboard
The Ransomware dashboard includes panes for viewing threats summary and its details,
managing and configuring ransomware protection, managing recovery settings, viewing blocked
clients (users or client IP addresses), and viewing and updating blocked file signatures.
The
Ransomware
dashboard includes the following sections:
The
Threats Summary
pane displays the highlighted threats and its
details (impacted shares, users, client IP address, and impacted files). You can view the
threat summary for last 24 hours, last 7 days, last 30 days, and last one year. By
default, last 24 hours summary is selected. Click the
View Details
link to see the threat details and impacted files.
The
Recovery (SSR) Enablement by Shares
pane for viewing and
enabling Self Service Restore (SSR). SSR snapshots are used for data recovery. To protect
the shares with configured SSR policy, enable SSR for the shares, see Enabling SSR.
The
Blocked Entities
pane for viewing the blocked IP addresses
and users suspected to be the source of ransomware attack.
The
Blocked Files Signatures
pane for viewing the number of
blocked ransomware signatures configured on the subscribed file server. Click
Download List (.csv)
to download a list of blocked ransomware
signatures. To update blocked signature list, click
Update Blocked Signature
List
or click
Settings
>
Update Signature List
. See
Updating Signature List
Click
Unblock
to revert access of File Server from
Read Only
mode to
Read Write
mode.
To enable or disable, and configure ransomware protection, click
Settings
. See Enabling Ransomware Protection
and Configuring Ransomware Protection Policy.
Figure.
Ransomware Dashboard
Click to enlarge
Viewing Threat Details and Impacted Files
The
Threats Summary
pane of the ransomware dashboard displays
the highlighted threats and its details (impacted shares, users, client IP address, impacted
files, and Recover).
About this task
To view the threat details and the impacted files, do the following:
Procedure
Click
All Threats
.
A list of all threats appears.
Click
View Files
in the
Details
column or click
Impacted Files
tab on the top.
Figure.
All Threats Tab View
Click to enlarge
The impacted files are listed.
In the impacted files tab view, you can do the following:
Select the scope and apply the filter to view the filtered list of
impacted files. You can filter based on the
Share
Name
.
Client IPs
, and
Client Username
.
Enter the file name, and then click
Search
to
search for a file name from the list.
Click the file name to view the audit details of the file. A graph
displaying the operations performed on the file, and the audit details of
the operations of the file (user name, client IP address, operation,
operation date) are listed in a table.
Note:
You can filter audit details
based on date of audit and operations.
Click
Recover
to view the recommended snapshot to
recover from the selected share. You must see a pop-up window with the
snapshot details, steps for recovery, and a download link to get a script
which helps automate the recovery of the selected share .
Figure.
Impacted Files Tab View
Click to enlarge
Figure.
Steps to Recover Impacted files
Click to enlarge
Enabling Ransomware Protection
Enable ransomware protection on your file server.
About this task
Procedure
Go to
collapse menu
>
Ransomware Protection
.
Click
Enable Ransomware Protection
. See Configuring Ransomware Protection Policy for configuration steps.
Click
Enable
.
The ransomware dashboard is now displayed.
(optional) To disable the ransomware protection, on the ransomware dashboard,
click
Settings
>
Disable Ransomware Protection
.
The ransomware protection is now disabled.
Configuring Ransomware Protection Policy
Configure ransomware protection policies on file servers.
About this task
Do the following to configure a ransomware protection policy on a file server.
Procedure
In the Global Dashboard, go to
collapse menu
>
Data Source
>
File Servers
and select the file server.
The file server dashboard appears.
Go to
collapse menu
>
Ransomware Protection
.
(optional) Click
Settings
>
Edit Policy Configuration
, to set policy to prevent ransomware attacks.
The
Ransomware Protection Policy Configuration
appears.
In the
Ransomware Protection Policy Configuration
page, do
the following:
(optional) Click
Download List (.csv)
, to
download a list of blocked ransomware signatures.
From Files 4.2, in
Remediation of Malicious
clients
select the
Block clients on all shares
to
block specific clients from accessing all the share in the event of
a ransomware attack.
select the
Make files Server Read -only
to make file servers read only for all the clients.
select
No Action
send a notification email but
take no action on the entity.
Note:
Clients can be unblocked after you analyze the threat.
The default remediation action will be to
Block
clients on all shares
.
Figure.
Ransomware Protection Policy Configuration
Click to enlarge
Under
Email Recipients
, add email addresses separated by
comma.
Note:
Data Lens sends a notification to the specified email addresses when a
ransomware attack happens.
Click
Save
.
The ransomware protection policy is configured.
(Optional) To disable the ransomware protection policy, click
Settings
>
Disable Ransomware Protection
.
Updating Signature List
Searches, adds or removes a signature from the ransomware protection
list.
About this task
Note:
Nutanix does not recommend manipulating the blocked signatures through Nutanix
Files.
Do the following to add or remove a signature from the protection list.
Procedure
Go to
collapse menu
>
Ransomware Protection
.
Click
Settings
>
Update Signature List
.
You can also click
Update Blocked Signature List
in the
Blocked Files Signatures
pane of the ransomware
dashboard.
The
Update Blocked Signature List
window
appears.
In the
Update Blocked Signature List
window, do the
following:
(optional) Click
Download List (.csv)
, to
download a list of blocked ransomware signatures.
Enter the file signature in the
Search for
signatures
field, and then click the search icon to
search for a signature.
Note:
Add one or more comma separated signatures which may have wildcard
characters (* or ?) if required. For example, *file_name.doc*,
*file_name?.doc*, filename.docx, *.docx.
(Optional) Click
Add
to add a new signature to
the list.
(Optional) Click
Remove
to delete an existing
signature from the list.
Figure.
Update Blocked Signature List
Click to enlarge
Click
Close
.
Enabling SSR
Enable self-service restore (SSR) on shares identified by Data Lens.
About this task
Data Lens scans shares for SSR policies. Do the following to protect the shares with
the configured SSR policy.
Procedure
Click
collapse menu
>
Ransomware Protection
.
Click
Settings
>
Manage Recovery Settings
.
The
Enable SSR for Shares
window appears.
Click the
Enable
button next to the share for which you
need to enable SSR.
Figure.
Manage Recovery Settings
Click to enlarge
Click the close icon to close the window.
Unblocking Client IP Addresses
Unblocks the client IP addresses.
About this task
Do the following to unblock the blocked entities, such as client users and client IP
addresses, on a file server.
Procedure
From the
Global Dashboard
, click
collapse menu
>
Ransomware Protection
.
The
Ransomware Protection
page
appears.
From the
Blocked Entities
widget, click
View
Details
.
The
Blocked Entities
page appears with the following tabs:
Client IP Addresses
—Lists the blocked client IP
addresses.
Share with Restricted Access
—Lists the names of
blocked shares .
Blocked Time
-lists the time at which the client
was blocked on the share.
A list of blocked entities appears.
Figure.
Blocked Entities in 4.2 server
Click to enlarge
Figure.
Blocked Entities in 4.1 server
Click to enlarge
Check
Shares with Restricted access
to see the name of
blocked shares .
From the
Blocked Entities
widget, click
View
Details
and select the
Client IP
Addresses
and
Client users
to
Unblock
.
Select an entity from the list and click
Unblock
.
The
Unblock Client IP Addresses and Client User
window appears.
Figure.
Unblock Entities
Click to enlarge
Note:
When the unblock task is in progress, you cannot unblock another
entity from the same share.
You can select multiple entities from the same share and unblock
them.
You can also click
Filters
, enter the share
name, and then click
Search
to search filter
the blocked entities from the share.
Click the
Unblock
button to unblock the entity.
Note:
After you unblock an entity, the entity gets access to the file system and
can resume operations. Make sure that you have cleared the entity from all
malicious software before you unblock an entity.
(Optional) Click the gear icon, and select
Export CSV
or
Export JSON
to download a list of blocked entities to
a file in CSV or JSON format.
Smart Tiering
Manage hot, warm, and cold file server data.
Use Smart Tiering to maximize the available file server space by moving cold data from the
file server to an object store. Nutanix supports using Nutanix Objects, AWS Standard, AWS IA,
or Wasabi (S3 compatible storage) as the object storage, which you must configure before
setting up a tiering profile, for details on setting up Nutanix Objects, see the
Objects
User Guide
.
Tiered storage does not contain the full data set. The full metadata and pointers to tiered
data remain on the primary storage. However, tiering cold data to an object store does provide
storage cost benefits, which you can calculate using the cost savings widget in the
Data Tiering
tab. You can recall tiered data from the object store by
configuring an auto-recall policy during tiering policy creation, or by recalling data
manually. You can also specify retention policies that indicate how long deleted data remains
in secondary storage prior to permanent deletion.
Note:
If you have Files version 4.2.0 and above you will be able to create a tiering profile
with AWS Glacier storage class in addition to Object Store, AWS, and S3 compliant storage
classes.
Do the following to enable tiering on the file server:
Ensure that you have enabled the file server in Data Lens, see
Data Age Dashboard.
Review the "Limitations" section.
Review the Smart Tiering Requirements and Recommendations section.
Configure the tiering location and profile, see Configuring a Tiering Location.
Configure the tiering capacity threshold, see Setting a Capacity Threshold.
Configure a tiering criteria policy, see Creating a Tiering Policy.
Limitations
You can only have one tiering profile and tiering location per file server.
You can initiate
only
one tier and one recall job at a time.
You cannot evict tiered file data from the primary storage until all snapshots
containing the file expire.
You cannot tier files that are smaller than 64 KiB or larger than 5 TiB.
You cannot write to tiered (offline) files.
You can only configure tiering at the file-server level.
You can only manually recall a maximum of 100 files at a time.
After re-enabling versioning, tiering operations need a minimum of 10 minutes to
resume.
Files cannot compress data while tiering data to the object store.
Files does not tier sparse files.
The manual tier and recall operations have a timeout of 10 days, after which Data Lens
terminates the operation. To continue the tier or recall operation for the remaining
files, restart the operations.
Terminology
Capacity threshold
– The percentage of file server capacity you must reach
to trigger tiering operations.
Object store
– Secondary storage service.
Recall
– Migrating data from secondary to primary storage manually or
through an auto-recall policy.
Tiering
– Migrating cold data from primary to secondary storage.
Tiering profile
– The secondary storage location configuration, which
includes the object store, security keys, the storage bucket, and other details.
Smart Tiering Requirements and Recommendations
Meet the indicated requirements to configure and administer tiering.
General Requirements
Enable versioning on the object store bucket.
Meet the compatibility requirements as described in the
Data Lens Release
Notes
.
Network Requirements
All file server VMs (FSVMs) need to access
insights.nutanix.com
through Pulse.
All FSVMs need to use DNS to resolve the name
insights.nutanix.com
.
AWS Simple Storage Service (S3) Requirements
Have the following AWS IAM user permissions.
s3:GetBucketObjectLockConfiguration
s3:PutObject
s3:GetObject
s3:GetLifecycleConfiguration
s3:AbortMultipartUpload
s3:PutLifecycleConfiguration
s3:CreateBucket
s3:GetObjectTagging
s3:ListBucket
s3:PutObjectTagging
s3:GetBucketVersioning
s3:GetObjectVersion
s3:DeleteObject
Ensure that the security keys have the following permissions on the S3 bucket:
Set LifeCycle policy
Read and write
Set tags on object
List and write on object
Nutanix Objects Object Store Requirements
Use the bucket owner secret and access for tiering.
Ensure the owner has read and write permissions.
Security Recommendations
Nutanix recommends using the following security best practices:
Implement security best practices for AWS S3 as described on the AWS documentation
portal.
Do not use the same bucket for storing non-Nutanix Files data.
Do not manually delete or overwrite any object in the bucket, as this results in data
loss.
Disable the object lock.
Enable encryption on the bucket.
Have the permissions to query the
bucket location.
Do the following when changing security keys:
Ensure that both keys are valid when changing from key1 to key2.
Retire key1 from s3 only after updating key2 on the file server.
On AWS, Files sets the life-cycle rule on the bucket to garbage collect deleted objects.
Do not overwrite or remove the rule from S3. Do not apply another life-cycle rule to the
bucket.
For Nutanix Objects, provide security keys of the owner of the bucket.
Data Age Dashboard
The
Data Age
dashboard consists of the
Smart
Tiering
and
Explore
tabs.
Smart Tiering Tab
The
Smart Tiering
dashboard includes tools for managing the tiering
configuration of a file server and consists of the following primary elements:
The
Tiering Configuration
pane includes options to configure the
tiering location, configure the capacity threshold, and configure tiering policies.
The
Capacity Summary
pane provides an overview of data
distribution on the file server.
Tiering Summary
pane provides an activity monitor of tiering
operations.
Recall Summary
pane provides an activity monitor of recall
operations.
Figure.
Smart Tiering Tab
Click to enlarge
The following table provides a detailed description of the features of each pane in the
dashboard.
Table 1.
Smart Tiering Tab
Pane
Feature
Description
Tiering configuration
Tiering location
Indicates the name of the tiering profile and the object store type. Provides an
option to configure or edit the tiering location.
Capacity threshold
Indicates the configured capacity threshold and whether tiering is manual or
scheduled. Provides option to configure the capacity threshold, edit the capacity
threshold, and to set up a tiering schedule.
Tiering policy
Indicates the configured tiering policy. Provides option to define files for
tiering.
Capacity summary
File server and capacity
Indicates the name of the file server, the capacity used, and the total capacity
configured for the file server.
Data distribution on primary storage
Indicates the distribution of data on the file server by the space used, the
space planned for tiering, and the free space.
Note:
The widget refreshes
hourly.
Total tiered data
The amount of data that has been moved to tiered storage.
Current cost savings
The approximate amount of money saved from tiering data.
Configure cost model option
See Configuring Cost Savings.
Manual recall option
See Manually Recalling Tiered Data.
Tier data option
See Tiering Data Manually.
Tiering summary
Number of files tiered
Indicates the total number of files recalled for the specified interval.
Data tiered
Indicates the total amount of data tiered for the specified interval.
Data tiered graph
Displays the number of files tiered over time. Hovering over the data displays
the value for the time specified on the horizontal axis.
Recall summary
Number of files recalled
Indicates the total number of files recalled for the specified interval.
Data recalled
Indicates the total amount of data recalled for the specified interval.
Data recalled graph
Displays the number of files recalled over time. Hovering over the data displays
the value for the time specified on the horizontal axis.
Explore Tab
The explore tab consists of the following elements:
A
Filters
pane lets you filter entities by data age (heat).
A
Summary
tab displays a breakdown of data by heat for the
selected scope.
A
Trend
tab displays heat trends for a specified period (7 days,
1 month, or 1 year).
An
Edit Data Age Configuration
link lets you edit heat level
settings.
A
Data Distribution By Shares
table provides share-level details
for the selected entity or entities.
Configuring a Tiering Location
To tier data, configure a secondary storage object store.
About this task
A tiering profile includes the tiering location and defines the secondary storage
target, which is the object store.
Follow the steps as indicated to configure a
tiering profile:
Procedure
In the
Dashboard
for the file server, click
Smart Tiering Dashboard
in the
Data
Summary by Age and Storage Tier
pane.
Figure.
Set Up Tiering
Click to enlarge
In the
Tiering Configuration
pane, under
Tiering Location
, click
Add Tiering
Location
.
Update the fields in the tab with the indicated information.
Note:
Some fields may be unavailable for updates.
Name
: Enter a name of the tiering profile.
Store type
: Select a store type.
Service host
: Enter a URL of the tiering service
host.
Access key
: Enter the S3 access key ID for the
object store.
Secret key
: Enter the secret access key for
accessing the object store.
Bucket configuration
Bucket name
: Enter a name of the bucket
in the object store (you cannot change the name).
Retention period
: Enter a period for data
retention after deletion from the file server. (The default
retention period is 5 years and the minimum is 6 months).
Certificate
Certificate
: Upload a secure sockets
layer (SSL) certificate file.
Validate certificate
: Check this box to
enforce SSL certificate verification during tiering operations
after profile creation.
Setting a Capacity Threshold
Specify when to tier data.
About this task
Follow the steps as indicated.
Procedure
In the
Dashboard
for the file server, click
Smart Tiering Dashboard
in the
Data
Summary by Age and Storage Tier
pane.
In the
Tiering Configuration
pane, click
Set
a Capacity Threshold
.
To tier data based on a threshold of occupied capacity, check the
Set a Capacity Threshold
box.
In the
% of Primary Storage
field, enter an
integer that indicates the capacity percentage to trigger tiering
(minimum 1%).
Under
When to tier
, choose an option.
To trigger tiering manually after crossing the capacity threshold,
select the
Manual
option.
To configure a schedule for tiering data, choose
On a
Schedule
option.
Note:
If you choose the
Manual
option, follow the steps
in Tiering Data Manually to initiate tiering after
you observe that the file server reaches the configured capacity
threshold.
If you chose the
On a Schedule
option, do the following
in the indicated fields (otherwise, continue to the next step).
Note:
Data Lens sends tier requests to
the file server until the scheduled time. However, due to bandwidth, the
actual tiering operation on the file server can begin and end shortly after
the scheduled time.
Frequency
: Use the
every
day
option and do the following (or click
set
a custom window for each day
).
Start time
: Specify when to start tiering
operations.
End time
: Specify when to end tiering
operations.
(Optional) to customize the tiering schedule, click
set a
custom window for each day
, and do the following:
Select the desired tiering days.
For each day, specify the schedule for tiering operations in the
start time
and
end
time
fields.
Click
Save
.
Creating a Tiering Policy
Add a policy that defines when to tier cold data to object storage.
About this task
To create a tiering policy, do the following:
Procedure
In the
Dashboard
for the file server, click
Smart Tiering Dashboard
in the
Data
Summary by Age and Storage Tier
pane.
In the
Tiering Configuration
pane, under
Tiering Policy
, click
Define a Tiering
Policy
.
Under
Filters for Data to be Tiered
, do the
following:
Data Access Age (older than)
:
Enter an integer to specify the data age.
In the dropdown, select the unit of measurement (days, weeks,
months, years).
File Size (greater than)
:
Enter an integer for the minimum tiering file size (minimum 64
KB).
In the dropdown, select the unit of measurement (KB, MB,
GB).
File Type
:
In the dropdown, choose either the
is not
(exclude)
or the
is
(include)
option.
Enter a file extension and click the space bar (do not include a
period or forward slash). For example
jpg
,
png
, or
mpeg
.
File Owner
:
In the dropdown, choose either the
is not
(exclude)
or the
is
(include)
option.
Enter a user name and click the space bar. For example
UID:13199
or
nutanix\user
.
(Optional) under
Shares
, do the following:
To specify shares excluded from tiering, check the
Exclude
Shares
box.
Check the box next to shares to exclude.
To specify an auto recall policy, check the
Enable
Auto-Recall
box, and do the following in the indicated
fields.
In the
Times
field, specify the number of
times Files can retrieve a file from the object store, based on
inline reads, before triggering recall.
Note:
With inline read
events, a file server retrieves content from the object
store, rather than the read cache. You might read a file
multiple times from the read cache before retrieving it as
an inline read from the object store.
In the period field, specify an integer and unit of measurement
(days, weeks, months, years).
Click
Save
.
If you set a schedule for the capacity threshold, Data Lens
automatically triggers the tiering operation in Nutanix Files according to the
policy and threshold configuration. If you chose to manually trigger tiering,
you must trigger the operation after the file server meets the criteria in the
threshold and policy configuration.
Manually Recalling Tiered Data
Manually recall data from secondary to primary storage.
About this task
You can configure auto recall of data during tiering policy setup, see Creating a Tiering Policy. Otherwise, follow the steps as
indicated to manually recall data.
Procedure
In the
Dashboard
for the file server, click
Smart Tiering Dashboard
in the
Data
Summary by Age and Storage Tier
pane.
In the
Capacity Summary
pane, click
Manual
Recall
.
Select one of the following search options:
Files
Folder Path
Shares
Enter the name of the search target into the search bar.
Click
Search
.
In the action column, click
Recall
.
You can monitor the operation in the
Tasks
tab.
(Optional) Click
Cancel Recall
to cancel the recall
task.
Note:
You can also cancel the recall task from the
Tasks
tab. For more information see, Tasks Dashboard.
Tiering Data Manually
Manually initiate tiering.
About this task
If you did not choose to tier data on a schedule in the capacity threshold
configuration, tier data manually.
Procedure
In the
Dashboard
for the file server, click
Smart Tiering Dashboard
in the
Data
Summary by Age and Storage Tier
pane.
In the
Capacity Summary
pane, click
Tier
Data
.
An unavailable
Tier Data
button indicates that Data
Lens has not found enough tiering candidates on the file server and that the
file server has not reached the capacity threshold.
A dialogue window asks you to confirm the action.
Click
Confirm
.
Data Lens triggers the tiering operation in Nutanix Files. You can
monitor the operation in the
Tasks
tab.
(Optional) Click
Cancel Tiering
to cancel the tiering
task.
Note:
You can also cancel the tiering task from the
Tasks
dashboard. For more information see, Tasks Dashboard.
Updating a Tiering Configuration
Edit an existing tiering configuration.
About this task
Follow the steps as indicated.
Procedure
To update a tiering configuration, go to
Data Summary by Age and Storage Tier
>
Smart Tiering Dashboard
.
In the
Tiering Configuration
section, do one or more of
the following.
To update the tiering profile configuration, click
Edit
under
Tiering
Location
. Update one or more fields as described in
Configuring a Tiering Location. You can only
update the access key, secret key, profile name, or the
certificate.
To update the capacity threshold, click
Edit
under
Capacity Threshold
. Update one or more
fields as described in Setting a Capacity Threshold.
To update the tiering policy, click
Edit
under
Tiering Policies
. Update one or more fields
as described in Creating a Tiering Policy
Configuring Data Heat Levels
Update the values that constitute different data heat levels.
Procedure
In the
Data Age
widget, click
Explore
.
Click
Edit Data Age Configuration
.
Do the following in the
Hot Data
section:
In the entry field next to
Older Than
, enter an
integer.
In the dropdown, choose a value for
Week(s)
,
Month(s)
, or
Year(s)
.
Do the following in the
Warm Data
section to configure
two ranges :
In the first entry field, enter an integer to configure the first
range.
In the dropdown, choose a value for
Week(s)
,
Month(s)
, or
Year(s)
.
In the second entry field, enter an integer to configure the second
range.
In the dropdown, choose a value for
Week(s)
,
Month(s)
, or
Year(s)
.
Do the following in the
Cold Data
section to configure
four ranges :
In the first entry field, enter an integer to configure the first
range.
In the dropdown, choose a value for
Week(s)
,
Month(s)
, or
Year(s)
.
In the second entry field, enter an integer to configure the second
range.
In the dropdown, choose a value for
Week(s)
,
Month(s)
, or
Year(s)
.
In the 3rd entry field, enter an integer to configure the 3rd
range.
In the dropdown, choose a value for
Week(s)
,
Month(s)
, or
Year(s)
.
(optional) In the 4th entry field, enter an integer to configure the
4th range.
In the dropdown, choose a value for
Week(s)
,
Month(s)
, or
Year(s)
.
Click
Apply
.
Note:
The new values do not affect the already calculated heat statistics.
Data Lens uses the updated values for future heat
calculations.
Configuring Cost Savings
Configure the cost savings widget.
About this task
Configuring cost savings helps you estimate the amount of money saved by tiering
data.
Procedure
In the
Dashboard
for the file server, click
Smart Tiering Dashboard
in the
Data
Summary by Age and Storage Tier
pane.
In the
Capacity Summary
pane, click
Configure
Cost Model
.
Figure.
Configure Cost Savings
Click to enlarge
Do the following in the
Cost Model
window.
Under
On Premises File Storage
, enter a number
that indicates the on premises storage cost per year.
Under
Tiered Storage
, enter a number that
indicates the object storage cost per year.
Click
Save
.
The
Cost Savings
widget periodically updates and
displays the approximate cost savings from tiering.
Reports
Generate a report for entities on the file server.
Create a report with custom attribute values or use one of the Data Lens pre-canned report
templates. To create a custom report, specify the entity, attributes (and operators for some
attributes), attribute values, column headings, and the number of columns, see Creating a Custom Report. Pre-canned reports define most of the
attributes and headings based on the entity and template that you choose, see Creating a Pre-Canned Report. To schedule a report, see Scheduling a Report.
You can also rerun existing reports rather than creating new ones. After running a report,
you can download it as a JSON or CSV file.
Reports Page
The reports page provides options to create, schedule, and download
reports.
The
Reports
page consists of the following elements:
Instant Reports
and
Scheduled Reports
tabs
display reports in a tabular view.
Each report tab includes the following columns:
Report name
Status
Last run
Actions
In the
Actions
column, you can do the following:
Download reports as a JSON or as a CSV
Rerun reports
Delete reports.
The
Create a new report
button takes you to the
New
Report
view where you can create a custom report, create a report from a
template, and schedule reports.
Figure.
Reports Page
Click to enlarge
Clicking
Create a new report
takes you to the
New
Report
view, which includes
Report builder
and
Pre-canned Reports Templates
tabs.
The
Report builder
and
Pre-canned Reports
Templates
tabs include the following elements:
The
Define Report Type
section includes an
Entity
drop-down menu to select an entity.
The
Define Filters
section includes an
Attribute
drop-down menu and an option to add more attributes by
clicking
+ Add filter
.
The
Add/remove columns in this report
section displays the
default columns. Clicking the columns field lets you add additional columns. Clicking the
x
next to the column name removes it from the report.
The
Define number of maximum rows in this report
section includes
a
Count
field to specify the number of rows in the report.
A
Schedule Report
option lets you schedule future reports.
Table 1.
Report Builder – Filter Options
Entity
Attributes (filters)
Operator
Value
Column
Events
event_date
equal_to
greater_than
greater_than_equal_to
less_than
less_than_equal_to
(date)
audit_path (object path)
audit_objectname (object name)
audit_operation (operation)
audit_machine_name (source of operation)
audit_event_date (event date in UTC)
audit_username (user name)
Event_operation
N/A
file_write
file_read
file_create
file_delete
rename
directory_create
directory_delete
SecurityChange (permission change)
set_attr
sym_link
Files
Category
equal_to
greater_than
greater_than_equal_to
less_than
less_than_equal_to
(date)
object_name (file name)
share_UUID (share name)
object_owner_name (owner name)
object_size_logical (size)
file_type (extension)
object_creation_date (creation date in UTC)
last_event_date (access date in UTC)
share_UUID (share name)
fileserver_protocol
object_ID (file id)
object_last_operation_name (last operation)
audit_username (last operation user
object_last_operation_name (last operation)
file_path (file path)
Extensions
N/A
(type in value)
Deleted
N/A
Last (number of days from 1 to 30) days
creation_date
equal_to
greater_than
greater_than_equal_to
less_than
less_than_equal_to
(date)
access_date
equal_to
greater_than
greater_than_equal_to
less_than
less_than_equal_to
(date)
Size
equal_to
greater_than
greater_than_equal_to
less_than
less_than_equal_to
(number) (file size)
File size options:
B
KB
MB
GB
TB
Folders
Deleted
N/A
Last (number of days from 1 to 30) days
object_name (Dir name)
object_owner_name (owner name)
object_creation_date (creation date in UTC)
last_event_date (access date in UTC)
share_UUID (share name)
object_last_operation_name (last operation)
audit_username (last operation user)
File server protocol
object_ID (file id)
file_path (Dir path)
creation_date
equal_to
greater_than
greater_than_equal_to
less_than
less_than_equal_to
(date)
Users
last_event_date
equal_to
greater_than
greater_than_equal_to
less_than
less_than_equal_to
(date)
user_login_name (user name)
Last operation
last_event_date (access date in UTC)
last_operation_audit_path
Table 2.
Pre-Canned Reports – Filters
Entity
Pre-canned report template
Columns
Events
Permission denied events
Permission denied (file blocking) events
audit_path (object path)
audit_objectname (object name)
audit_operation (operation)
audit_machine_name (source of operation)
audit_event_date (event date in UTC)
audit_username (user name)
Files
Largest files
Oldest files
Files not accessed for last 1 year
Files accessed in last 30 days
object_name (file name)
share_UUID (share name)
object_owner_name (owner name)
object_size_logical (size)
file_type (extension)
object_creation_date (creation date in UTC)
last_event_date (access date in UTC)
share_UUID (share name)
fileserver_protocol
object_ID (file id)
object_last_operation_name (last operation)
audit_username (last operation user
object_last_operation_name (last operation)
file_path (file path)
Users
Top owners with space consumed
Top active users
All users
user_login_name (user name)
Last operation
last_event_date (access date in UTC)
last_operation_audit_path
Creating a Custom Report
Create a custom report by defining the entity, attribute, filters, and
columns.
About this task
Follow the steps as indicated.
Procedure
Go to
collapse menu
>
Reports
.
Click
Create a new report
.
In the
Report Builder
tab, do the
following:
In the
Define Report Type
section, select an
entity from the drop-down menu.
In the
Define Filters
section, select an
attribute from the attributes drop-down menu.
Under
Value
, specify the values for the
attribute (some attributes also require to specify an operator in the
Operator
field).
(optional) click
+ Add filter
to add more
attributes.
In the
Add/Remove column in this report
section,
click the field to display column options and select desired columns for
the report. You can also click
x
for the columns
you want to remove.
In the
Define maximum number of rows in this
report
section, specify the number of rows in your
report. This value indicates the number of records in the report.
Click
Run Preview
.
The
Report Preview
section
populates.
Click
Generate report
. (Or schedule a report, see Scheduling a Report.)
Select either the
CSV
or
JSON
option.
Creating a Pre-Canned Report
Use one of the pre-canned Data Lens templates for your report.
Procedure
Go to
collapse menu
>
Reports
.
Click
Create a new report
.
In the
Pre-Canned Reports Templates
tab, do the
following:
In the
Define Report Type
section, select an
entity from the drop-down menu.
In the
Define Filters
section, select an
attribute from the attributes drop-down menu.
In the
Add/Remove column in this report
section,
click the field to display column options and select desired columns for
the report. You can also click
x
for the columns
you want to remove.
In the
Define maximum number of rows in this
report
section, specify the number of rows in your
report. This value indicates the number of records in the report.
Click
Run Preview
.
The
Report Preview
section
populates.
Click
Generate report
. (Or schedule a report, see Scheduling a Report.)
Follow the steps as indicated to schedule a report.
Procedure
Follow the procedure for creating a report and
Run
Preview
, but do not generate the report. See Creating a Custom Report or Creating a Pre-Canned Report.
Click
Schedule Report
.
In the
Schedule Report
dialog box, do the following in
the indicated fields:
Time Zone
: Select a time zone in which to
schedule the report.
Report
Frequency
: Select the report
frequency from
Daily
,
Weekly
, or
Monthly
.
This also defines the interval for which Data Lens collects data.
Choose Recipients
: In the
Email
Recipients
field, enter a comma-separated list of report
recipients.
Click
Next
.
Under
Define the report format
, select either
JSON
or
CSV
.
Under
Define the title for your report
, enter a report
title.
Click
Schedule Report
.
The scheduled report appears in the
Scheduled
Reports
tab on the
Reports
page.
Tasks
View the tasks on the file server.
The
Tasks
dashboard displays a table with the status and other details
of the tasks.
Tasks Dashboard
The Tasks dashboard displays the tasks that are in queue, in-progress, canceled, or in
failed status.
The
Task
dashboard lists the following options. You can filter the
tasks based on these options.
Queued—The tasks in the queue.
Running—The tasks currently in progress. Hover over this status to view the total number
of files tiered or recalled so far until the task is complete.
Successful—The tiering or recall request task to Files is complete.
Failed—The tasks that did not complete successfully.
Canceled—The tasks that are cancelled.
Cancel Requested—The tasks that are requested for cancellation.
Canceling—The tasks that are currently being cancelled.
Figure.
Tasks Dashboard
Click to enlarge
The tasks table lists the following details:
Operation—The type of operation the task performs. For example, tier request, recall
request, create tiering location, enable ransomware, and so on.
Status—Task status such as, successful, canceled, and canceling. Hover over the status to
view the details.
Creation Time—The time when the task was created.
Last Updated Time—The time when the task was last updated.
Submitted By—The name of the task submitter.
Action—A
Cancel
button appears for user recall tasks and tiering
operations (operation type is tier request or recall request). You can click the
Cancel
button to cancel these tasks before it completes. After the
cancel request is complete, the task status changes to canceled. You can cancel tasks with
queued or running status.
Note:
Account administrators can cancel tasks submitted by any user. Data Lens
administrators can cancel the tasks they submitted. However, Data Lens Users (if the
user is a viewer), cannot cancel any tasks.
Hover over the
Cancel
button to view the total number of
tiered or recalled files and the name of the user who canceled the task.
Data Lens Options
You can get more insight into the usage and contents of files on your system by configuring
and updating
Data Lens
features and settings. Some options include scanning
the files on your file server on demand, updating data retention, and configuring data
protection.
Updating Data Retention
The data retention period determines how long Data Lens retains event
data.
About this task
Follow the steps as indicated to configure data retention.
Procedure
In Data Lens, click
gear icon
>
Update Data Retention
.
In the
Data Retention Period
drop-down, select the
period for data retention.
Click
Update
.
Scanning the File System
Once enabled, Data Lens scans the metadata of all files and shares on the system. You
can perform an on-demand scan of shares in your file system when new shares are created
after the initial scan.
About this task
Note:
Enabling Data Lens for a file server triggers scan for all shares as part of
the enablement process and triggers the metadata collection. Triggering subsequent
scans interferes with and overwrites the collected metadata and is not recommended
unless initial scan has some issue or if any new shares are created.
To scan
shares, perform the following task.
Procedure
In Data Lens, click the
gear icon
.
In the drop-down list, click
Scan File System
.
In the list of shares, select the target shares for the scan.
Figure.
Select Scan Targets
Click to enlarge
Click
Scan
.
The status of the share is
In Progress
. Once the
scan is complete, the status changes to
Completed
. You
can view the number of files scanned with the scan date and time.
Managing File Categories
Data Lens uses the file category configuration to classify file extensions.
About this task
The capacity widget in the dashboard uses the category configuration to calculate
capacity details.
Procedure
Click
gear icon
>
Manage File Category
.
To create a category, click
+ New Category
. (Otherwise,
move on to step 3).
In the
Category
column, name the category.
In the
Extensions
column, specify file
extensions for the category.
To delete an existing category, click the
x icon
next to
the category. (Otherwise, move on to step 4)
To modify an existing category, click the
pencil icon
next to the category and modify the specified file extensions.
Click
Save
.
Deleting Audit Data
Delete file server audit data or clean up the analyzed data of already deleted files
and folders.
About this task
Follow the steps as indicated.
Procedure
Click
gear icon
>
Manage Data
.
Caution:
The deleted File Server data cannot be
retrieved.
(optional) To delete audit data for the entire file server, go to the
File Server
tab, and then click the
delete the audit data
>
Delete
.
The deletion of File Server data can be used to reduce the usage from the
allocated license capacity.
Note:
Delete option is only available for disabled File Server.
(optional) To delete data for one or more shares, go to the
Manage
Share/Export Audit Data
tab.
Caution:
The deleted audit data cannot be
retrieved.
Select one or more share or exports.
To delete a single share or export, click
Delete
in the row for that
share.
To delete multiple shares or exports, select the shares to be
deleted, and then click
Delete
above the
table.
Caution:
The deleted data cannot be
retrieved.
(optional) To clean up the analyzed data of already deleted files and folders,
go to the
Manage Files/Folders Deleted Data
tab, and then
click the
delete the files/folders data
>
Delete
.
The clean up of the analyzed data of already deleted files and folders can be
done to reduce the usage from the allocated license capacity.
Note:
The
Manage Files/Folders Deleted Data
tab will only
be enabled if any deleted files or folders are available for that particular
File Server.
Once you have triggered for data deletion, you will be redirected to the
dashboard page.
Isilon Integration
Use Data Lens as a lightweight analytics solution for file servers on Dell EMC Isilon,
a third-party file server software.
Note:
The Dell EMC Isilon integration is a technical preview feature and
should not be used in a production environment. You might not be able to retain audit data or
upgrade file servers from technical preview to general availability (GA) versions.
The Data Lens integration with Isilon deploys an agent VM in the third-party environment of
the Isilon file server. The agent VM combines the capabilities of a syslog server and Isilon's
incremental scan to receive audit events, scan data, and send the heartbeat of the container
for health monitoring. Nutanix also collects insights data from your Isilon file server using
Pulse. Before enabling the Isilon file server on Data Lens, you must consent to insights data
collection, refer to "Nutanix Insights" in Support Portal Help.
As a lightweight analytics and monitoring solution, Data Lens for Isilon currently does not
include a full feature set, see Isilon Technical Preview for a list
of unsupported features. As a result, the Data Lens UI for Isilon includes fewer widgets. Some
of the supported features include audit trails, capacity trends, and heat monitoring. UI
updates include a column listing the vendor in the file server table on the Global Dashboard
and a new
Registered Agents
view for monitoring all registered agents.
If the agent VM is down for 24 hours, an automated alert goes out to Nutanix Support.
Deploying and managing Data Lens for Isilon requires the following:
Installing an agent VM, see Installing an Agent VM.
Enabling the Isilon server and accepting the license agreement, see Enabling a File Server.
Monitoring the registered agent VM in the
Registered Agents
view,
see Isilon Technical Preview.
Configuring a syslog server in the Isilon environment. See the
EMC Isilon Auditing
Guide
for steps to configure a syslog server.
Isilon Technical Preview
Technical preview of the Data Lens integration with Dell EMC Isilon.
This document describes the user experience for Data Lens with Isilon.
Lightweight Feature Set
Data Lens for Isilon provides general storage capacity reporting and audit visibility.
The Isilon
integration does not include the following elements and features:
Share-level details in the main dashboard
Smart Tiering
Anomaly detection
Ransomware protection
The agent VM has the following limitations and restrictions:
You cannot change the name of the agent VM.
You cannot clone the agent VM.
If you delete the agent VM, any files or directories on the VM are also deleted.
The Data Lens UI does not register changes to the agent VM IP address. Re-run the
registration command to display the updated IP address.
A backward slash in a file name causes the name and parent directory of a file to
display incorrectly in audit trails.
Registered Agents View
Clicking the
gear icon
>
Registered Agents
displays a tabular view of all the agents in
Registered Agents
view. The following describes the columns in the table of the
Registered Agents
view:
Table 1.
Registered Agents View
Column
Description
Name
Agent VM name
IP address
IP address of the host where the agent VM is registered.
ID
Unique identifier for the agent VM.
No. of file servers served
Number file servers on the host that the agent VM supports.
Active and offline agents
Red and green icons indicate if the agent VM is on line (green) or off line
(red).
Installing an Agent VM
Install a Data Lens agent VM in your third-party environment.
About this task
Follow the steps as indicated:
Procedure
In the
File Server
section of the Global Dashboard,
click
+Add a File Server
.
In the drop-down menu following
Isilon
, select
Install a new agent
.
Download and configure the agent VM:
To download the agent VM image, click the link in the
Download an agent VM image from here
line.
Create an agent VM with the following minimum requirements.
Note:
The newly created VM has default Nutanix
credentials. Make sure to update the credentials.
(See "Creating a VM" in the
Prism Self Service Administration
Guide
.)
1 vCPU
4 cores
12 GB RAM
Minimum 120 GiB storage
Allow HTTPS traffic from the agent VM to
insights.nutanix.com
.
Register the VM with Data Lens using the provided token in the
Add File Server
view of the
Global
Dashboard
.
Replace
add_server
with the name of the file
server. Replace
IP/Host-name
with the IP address of
the host. Replace
REST-api-port
with the port number
for REST API communication. Replace
Isilon-server-user
with your user name. Replace
password-file-name
with the name and path to your
password file.
Once the task completes, the server displays in the Data Lens
File Server
view.
What to do next
Configure a syslog server in the EMC Isilon environment to communicate with the
agent VM. For steps to configure a syslog server, see the
EMC Isilon Auditing
Guide
.
Next, enable the Isilon file server, see Enabling a File Server.
Replace
add_server
with the name of the file server.
Replace
IP/Host-name
with the IP address of the Isilon
management host. Replace
REST-api-port
with the port number
for REST API communication. Replace
Isilon-server-user
with
your user name. Replace
password-file-name
with the name and
path to your password file.
After adding the file servers, run a full scan on
all of the added file servers.
Once the task completes, the server displays in the Data Lens
File Server
view.
What to do next
Perform a full scan, see Scanning the File System.
Legacy disaster recovery (DR) configurations use protection domains (PDs) and third-party
integrations to protect your applications. These DR configurations replicate data between
on-prem Nutanix clusters. Protection domains provide limited flexibility in terms of
supporting complex operations (for example, VM boot order, network mapping). With protection
domains, you have to perform manual tasks to protect new guest VMs as and when your
application scales up.
Nutanix Disaster Recovery
offers an entity-centric automated approach
to protect and recover applications. It uses categories to group the guest VMs and automate
the protection of the guest VMs as the application scales. Application recovery is more
flexible with network mappings, an enforceable VM start sequence, and inter-stage delays.
Application recovery can also be validated and tested without affecting your production
workloads. Asynchronous, NearSync, and Synchronous replication schedules ensure that an
application and its configuration details synchronize to one or more recovery locations for a
smoother recovery.
Note:
You can protect a guest VM either with legacy DR solution (protection domain-based) or
with new
Nutanix Disaster Recovery
. To see various Nutanix DR
solutions, refer Nutanix Disaster Recovery Solutions.
Nutanix Disaster Recovery
works with sets of physically isolated
locations called availability zones. An instance of Prism Central represents an availability
zone. One availability zone serves as the primary AZ for an application while one or more
paired availability zones serve as the recovery AZs.
Note:
Nutanix Disaster Recovery
supports the use of Flow Virtual
Networking enabled Virtual Private Clouds.
Figure.
A primary on-prem AZ and one recovery on-prem AZ
Click to enlarge
Figure.
A primary on-prem AZ and two recovery on-prem AZs
Click to enlarge
Figure.
A primary on-prem AZ and two recovery AZs: one on-prem recovery AZ and one
recovery AZ in Cloud (Xi Cloud Services)
Click to enlarge
Figure.
A primary on-prem AZ and one recovery AZ at Xi Cloud Services
Click to enlarge
Figure.
A primary Nutanix cluster and at most two recovery Nutanix clusters at the same on-prem
AZ
Click to enlarge
Figure.
A primary AZ at Xi Cloud Services and recovery on-prem AZ
Click to enlarge
When paired, the primary AZ replicates the entities (protection policies, recovery plans,
and recovery points) to the recovery AZs in the specified time intervals (RPO). The approach
helps application recovery at any of the recovery AZs when there is a service disruption at
the primary AZ (For example, natural disasters or scheduled maintenance). The entities start
replicating back to the primary AZ when the primary AZ is up and running to ensure High
Availability of applications. The entities you create or update synchronize continuously
between the primary and recovery AZs. The reverse synchronization enables you to create or
update entities (protection policies, recovery plans, or guest VMs) at either the primary or
the recovery AZs.
This guide is primarily divided into the following two parts.
Protection and DR between On-Prem AZs (Nutanix Disaster Recovery)
The section walks you through the procedure of
application protection and DR to other Nutanix clusters at the same or different on-prem
AZs. The procedure also applies to protection and DR to other Nutanix clusters in
supported public cloud.
Protection and DR between On-Prem AZ and Xi Cloud Service (Xi Leap)
Xi Leap is essentially an extension of Leap to Xi
Cloud Services. You can protect applications and perform DR to Xi Cloud Services or from
Xi Cloud Services to an on-prem availability zone. The section describes application
protection and DR from Xi Cloud Services to an on-prem Nutanix cluster. For application
protection and DR to Xi Cloud Services, refer the supported capabilities in Protection and DR between On-Prem AZs (Nutanix Disaster Recovery) because the protection procedure remains the same when the
primary AZ is an on-prem availability zone.
Configuration tasks and DR workflows are largely the same regardless of the type of recovery
AZ. For more information about the protection and DR workflow, see Nutanix Disaster Recovery Deployment Workflow.
Nutanix Disaster Recovery Terminology
The following section describes the terms and concepts used throughout the guide.
Nutanix recommends gaining familiarity with these terms before you begin configuring protection
with
Nutanix Disaster Recovery
or Xi Leap disaster recovery.
Availability Zone (AZ)
A zone that can have one or more independent datacenters inter-connected by low latency
links. An AZ can either be in your office premises (on-prem) or in Xi Cloud Services. AZs
are physically isolated from each other to ensure that a disaster at one AZ does not affect
another AZ. An instance of Prism Central represents an on-prem AZ.
On-Prem Availability Zone
An AZ in your premises.
Xi Cloud Services
An AZ in the Nutanix Enterprise Cloud Platform (Xi Cloud Services).
Primary Availability Zone
An AZ that initially hosts guest VMs you want to protect.
Recovery Availability Zone
An AZ where you can recover the protected guest VMs when a planned or an unplanned event
occurs at the primary AZ causing its downtime. You can configure at most two recovery
AZs for a guest VM.
Nutanix Cluster
A cluster running AHV or ESXi nodes on an on-prem AZ, Xi Cloud Services, or any supported
public cloud. Leap does not support guest VMs from Hyper-V clusters.
Prism Element
The GUI that provides you the ability to configure, manage, and monitor a single Nutanix
cluster. It is a service built into the platform for every Nutanix cluster deployed.
Prism Central
The GUI that allows you to monitor and manage many Nutanix clusters (Prism Element running
on those clusters). Prism Starter, Prism Pro, and Prism Ultimate are the three flavors of
Prism Central. For more information about the features available with these licenses, see
Software Options.
Prism Central essentially is a VM that you deploy (host) in a Nutanix cluster (Prism
Element). For more information about Prism Central, see Prism Central Guide. You can set up the following
configurations of Prism Central VM.
Small Prism Central
A Prism Central VM with configuration equal to or less than 8 vCPU and 32 GB memory.
The VM hot adds extra 4 GB and 1 GB memory when you enable Leap and Flow respectively in
small Prism Central.
Small Prism Central (Single node)
A small Prism Central deployed in a single VM.
Small Prism Central (Scaleout)
Three small Prism Centrals deployed in three VMs in the same availability zone
(AZ).
Large Prism Central
A Prism Central VM with configuration more than 8 vCPU and 32 GB memory. The VM hot
adds extra 8 GB and 1 GB memory when you enable Leap and Flow respectively in large
Prism Central.
Large Prism Central (Single node)
A large Prism Central deployed in a single VM.
Large Prism Central (Scaleout)
Three large Prism Centrals deployed in three VMs in the same availability zone
(AZ).
Note:
A scaleout Prism Central works like a single node Prism Central in the availability zone
(AZ). You can upgrade a single node Prism Central to scaleout Prism Central to increase the
capacity, resiliency, and redundancy of Prism Central VM. For detailed information about the
available configurations of Prism Central, see
Prism Central Scalability
in
Prism Central Release Notes.
Virtual Private Cloud (VPC)
A logically isolated network service in Xi Cloud Services. A VPC provides the complete IP
address space for hosting user-configured VPNs. A VPC allows creating workloads manually or
by failover from a paired primary AZ.
The following VPCs are available in each Xi Cloud Services account. You cannot create more
VPCs in Xi Cloud Services.
Production VPC
Used to host production workloads.
Test VPC
Used to test failover from a paired AZ.
Source Virtual Network
The virtual network from which guest VMs migrate during a failover or failback.
Recovery Virtual Network
The virtual network to which guest VMs migrate during a failover or failback operation.
Network Mapping
A mapping between two virtual networks in paired AZs. A network mapping specifies a
recovery network for all guest VMs of the source network. When you perform a failover or
failback, the guest VMs in the source network recover in the corresponding (mapped) recovery
network.
Category
A VM category is a key-value pair that groups similar guest VMs. Associating a protection
policy with a VM category ensures that the protection policy applies to all the guest VMs in
the group regardless of how the group scales with time. For example, you can associate a
group of guest VMs with the
Department: Marketing
category, where
Department
is a category that includes a value
Marketing
along with other values such as
Engineering
and
Sales
.
VM categories remain the same way on on-prem AZs and Xi Cloud Services. For more
information about VM categories, see
Category Management
in
Prism Central
Guide
.
Recovery Point
A copy of the state of a system at a particular point in time.
Crash-consistent Snapshots
A snapshot is crash-consistent if it captures all of the data components (write order
consistent) at the instant of the crash. VM snapshots are crash-consistent (by default),
which means that the vDisks that the snapshot captures are consistent with a single
point in time. Crash-consistent snapshots are more suited for non-database operating
systems and applications which may not support quiescence (freezing) and un-quiescence
(thawing) and such as file servers, DHCP servers, print servers.
Application-consistent Snapshots
A snapshot is application-consistent if, in addition to capturing all of the data
components (write order consistent) at the instant of the crash, the running
applications have completed all their operations and flushed their buffers to disk (in
other words, the application is quiesced). Application-consistent snapshots capture the
same data as crash-consistent snapshots, with the addition of all data in memory and all
transactions in process. Therefore, application-consistent snapshots may take longer to
complete.
Application-consistent snapshots are more suited for systems and
applications that can be quiesced and un-quiesced or thawed, such as database
operating systems and applications such as SQL, Oracle, and Exchange.
Recoverable Entity
A guest VM that you can recover from a recovery point.
Protection Policy
A configurable policy that takes recovery points of the protected guest VMs in equal time
intervals, and replicates those recovery points to the recovery AZs.
Recovery Plan
A configurable policy that orchestrates the recovery of protected guest VMs at the recovery
AZ.
Recovery Point Objective (RPO)
The time interval that refers to the acceptable data loss if there is a failure. For
example, if the RPO is 1 hour, the system creates a recovery point every 1 hour. On
recovery, you can recover the guest VMs with data as of up to 1 hour ago.
Take
Snapshot Every
in the
Create Protection Policy
GUI
represents RPO.
Recovery Time Objective (RTO)
The time period from failure event to the restored service. For example, an RTO of 30
minutes enables you to back up and run the protected guest VMs in 30 minutes after the
failure event.
Nutanix Disaster Recovery Solutions
The following flowchart provides you with the detailed representation of the disaster
recovery (DR) solutions of Nutanix. This decision tree covers both the DR solutions—protection
domain-based DR and
Nutanix Disaster Recovery
helping you to make
quick decisions on which DR strategy will best suit your environment.
Figure.
Decision Tree for Nutanix DR Solutions
Click to enlarge
For information about protection domain-based (legacy) DR, see
Data Protection and
Recovery with Prism Element
guide. With Leap, you can protect your guest VMs and
perform DR to on-prem availability zones (AZs) or to Xi Cloud Services. A Leap deployment
for DR from Xi Cloud Services to an on-prem Nutanix cluster is Xi Leap. The detailed
information about Leap and Xi Leap DR configuration is available in the following sections of
this guide.
Protection and DR between On-Prem AZs (Nutanix Disaster Recovery)
For information about protection with Asynchronous replication schedule and DR, see Protection with Asynchronous Replication Schedule and DR (Nutanix Disaster Recovery).
For information about protection with NearSync replication schedule and DR, see Protection with NearSync Replication Schedule and DR (Nutanix Disaster Recovery).
For information about protection with Synchronous replication schedule and DR, see Protection with Synchronous Replication Schedule (0 RPO) and DR.
Protection and DR between On-Prem AZ and Xi Cloud Service (Xi Leap)
For information about protection with Asynchronous replication schedule and DR, see Protection with Asynchronous Replication and DR (Xi Leap).
For information about protection with NearSync replication schedule and DR, see Protection with NearSync Replication and DR (Xi Leap).
Nutanix Disaster Recovery Deployment Workflow
The workflow for entity-centric protection and disaster recovery (DR) configuration
is as follows. The workflow is largely the same for both
Nutanix Disaster Recovery
and Xi Leap configurations except a few
extra steps you must perform while configuring Xi Leap.
Procedure
Enable Leap at the primary and recovery on-prem AZs (Prism Central).
Enable Leap at the on-prem AZ only. For more information about enabling Leap,
see Enabling Nutanix Disaster Recovery for On-Prem AZ.
Pair the primary and recovery AZs with each other.
Only when you pair an AZ, the AZ lists while configuring recovery AZ in
protection policies and recovery plans (see step 6 and step 7). For more
information about pairing the AZs, see Pairing AZs (Nutanix Disaster Recovery).
(only for Xi Leap configuration) Set up your environment to proceed with
replicating to Xi Cloud Services.
For more information about environment setup, see Xi Leap Environment Setup.
(only for Xi Leap configuration) Reserve floating IP addresses.
For more information about floating IP addresses, see Floating IP Address Management in
Xi Infrastructure Service Management Guide
.
Create production and test virtual networks at the primary and recovery
AZs.
Create production and test virtual networks only at the on-prem AZs. Xi
Cloud Services create production and test virtual networks dynamically for you.
However, Xi Cloud Services provides floating IP addresses (step 4), a feature
that is not available for on-prem AZs. For more information about production
and test virtual networks, see Nutanix Virtual Networks.
Create a protection policy with replication schedules at the primary AZ.
A protection policy can replicate recovery points to at most two other Nutanix
clusters at the same or different AZs. To replicate the recovery points, add a
replication schedule between the primary AZ and each recovery AZ.
To create a protection policy with an Asynchronous replication schedule,
see:
Creating a Protection Policy with an Asynchronous Replication Schedule (Nutanix Disaster Recovery)
Creating a Protection Policy with Asynchronous Replication Schedule (Xi Leap)
To create a protection policy with a NearSync replication schedule, see:
Creating a Protection Policy with a NearSync Replication Schedule (Nutanix Disaster Recovery)
Creating a Protection Policy with NearSync Replication Schedule (Xi Leap)
Note:
To maintain the efficiency of minutely replication,
protection policies allow you to add NearSync replication schedule
between the primary AZ and only one recovery AZ.
To create a protection policy with the Synchronous replication schedule,
see Creating a Protection Policy with the Synchronous Replication Schedule.
Note:
To maintain the efficiency of synchronous replication,
protection policies allow you to add only one recovery AZ when you
add Synchronous replication schedule. If you already have an
Asynchronous or a NearSync replication schedule in the protection
policy, you cannot add another recovery AZ to protect the guest VMs
with Synchronous replication schedule.
You can also create a protection policy at a recovery AZ. Protection
policies you create or update at a recovery AZ synchronize back to the primary
AZ. The reverse synchronization helps when you protect more guest VMs in the
same protection policy at the recovery AZ.
Create a recovery plan at the primary AZ.
A recovery plan orchestrates the failover of the protected guest VMs (step 6)
to a recovery AZ. For two recovery AZs, create two discrete recovery plans at
the primary AZ—one for DR to each recovery AZ.
To create a recovery plan for DR to another Nutanix cluster at the same
or different on-prem AZs, see Creating a Recovery Plan (Nutanix Disaster Recovery).
To create a recovery plan for DR to Xi Cloud Services, see Creating a Recovery Plan (Xi Leap).
You can also create a recovery plan at a recovery AZ. The recovery plan you
create or update at a recovery AZ synchronizes back to the primary AZ. The
reverse synchronization helps in scenarios where you add more guest VMs to the
same recovery plan at the recovery AZ.
Validate or test the recovery plan you create in step 7.
To test a recovery plan, perform a test failover to a recovery AZ.
To perform test failover to another Nutanix cluster at the same or
different on-prem AZs, see Performing a Test Failover (Leap).
To perform test failover to Xi Cloud Services, see Failover and Failback Operations (Xi Leap).
(only for Xi Leap configuration) After the failover to recovery AZ, enable
external connectivity. To enable external connectivity, perform the
following.
After a planned failover, shut down the VLAN interface on the
on-prem Top-of-Rack (TOR) switch.
To access the Internet from Xi Cloud Services, create both
inbound and outbound policy-based routing (PBR) policies on the
virtual private cloud (VPC). For more information, see Policy Configuration
in
Xi Infrastructure Service Administration
Guide
.
(only for Xi Leap configuration) Perform the following procedure to access the
recovered guest VMs through the Internet.
Assign a floating IP address to the guest VMs failed over to Xi
Cloud Services. For more information, see
Floating IP Address
Management
in
Xi Infrastructure Service
Administration Guide
Create PBR policies and specify the internal or private IP
address of the guest VMs. For more information, see Policy Configuration
in
Xi Infrastructure Service Administration
Guide
.
Note:
If a guest VM (that hosts a publicly accessible webAZ) fails over,
update the authoritative DNS server (for example, Amazon Route 53, GoDaddy,
DNSmadeEasy) with the primary failover record (on-prem public IP address)
and the secondary failover record (Xi floating IP address). For example, if
your authoritative DNS server is Amazon Route53, configure the primary and
the secondary failover records. Amazon Route53 performs the health checks on
the primary failover record and returns the secondary failover record when
the primary is down.
On-Prem Hardware Resource Requirements
For DR solutions with Asynchronous, NearSync, and Synchronous replication schedules to
succeed, the nodes in the on-prem AZs (AZs or AZs) must have certain resources.
This section provides information about the node, disk and Foundation configurations necessary
to support the RPO-based recovery point frequencies.
The conditions and configurations provided in this section apply to Local and Remote
recovery points.
Any node configuration with two or more SSDs, each SSD being 1.2 TB or greater
capacity, supports recovery point frequency for NearSync.
Any node configuration that supports recovery point frequency of six (6) hours also
supports AHV-based Synchronous replication schedules because a protection policy with
Synchronous replication schedule takes recovery points of the protected VMs every 6
hours. See Protection with Synchronous Replication Schedule (0 RPO) and DR for
more details about Synchronous replication.
Both the primary cluster and replication target cluster must fulfill the same minimum
resource requirements.
Ensure that any new node or disk additions made to the on-prem AZs (Availability
Zones) meet the minimum requirements.
Features such as Deduplication and RF3 may require additional memory depending on the
DR schedules and other workloads run on the cluster.
Note:
In case of on-prem deployments, the default minimum recovery point frequency using the
default Foundation configuration is 6 hours. To increase the recovery point frequency, you
must also modify the Foundation configuration (SSD and CVM) accordingly. For example, an
all-flash setup with a capacity between 48 TB to 92 TB has the default recovery point
frequency is 6 hours. If you want to decrease the recovery point interval to one (1) hour,
you must modify the default Foundation configuration to:
14 vCPUs for CVM
40 GB for CVM
The table lists the supported frequency for the recovery points across various hardware
configurations.
Table 1.
Recovery Point Frequency
Type of disk
Capacity per node
Minimum recovery point frequency
Foundation Configuration - SSD and CVM requirements
Hybrid
Total HDD tier capacity of 32 TB or lower. Total capacity (HDD + SSD) of 40 TB
or lower.
NearSync
Async (Hourly)
No change required—Default Foundation configuration.
2 x SSDs
Each SSD must be minimum 1.2 TB or more for NearSync.
Total HDD tier capacity between 32-64 TB. Total capacity (HDD + SSD) of 92 TB or
lower.
Up to 64 TB HDD
Up to 32 TB SSD (4 x 7.68 TB SSDs)
NearSync
Async (Hourly)
Modify Foundation configurations to minimum:
4 x SSDs
Each SSD must be minimum 1.2 TB or more for NearSync.
14 vCPU for CVM
40 GB for CVM
Total HDD tier capacity between 32-64 TB. Total capacity (HDD + SSD) of 92 TB or
lower.
Up to 64 TB HDD
Up to 32 TB SSD
Async (Every 6 hours)
No change required—Default Foundation configuration.
Total HDD tier capacity between 64-80 TB. Total capacity (HDD + SSD) of 96 TB or
lower.
Async (Every 6 hours)
No change required—Default Foundation configuration.
Total HDD tier capacity greater than 80 TB. Total capacity (HDD + SSD) of 136 TB
or lower.
Async (Every 6 hours)
Modify Foundation configurations to minimum:
12 vCPU for CVM
36 GB for CVM
All Flash
Total capacity of 48 TB or lower
NearSync
Async (Hourly)
No change required—Default Foundation configuration.
Total capacity between 48-92 TB
NearSync
Async (Hourly)
Modify Foundation configurations to minimum:
14 vCPU for CVM
40 GB for CVM
Total capacity between 48-92 TB
Async (Every 6 hours)
No change required—Default Foundation configuration.
Total capacity greater than 92 TB
Async (Every 6 hours)
Modify Foundation configurations to minimum:
12 vCPU for CVM
36 GB for CVM
Native Encryption of Replication Traffic
You can enable or disable encryption of the replication traffic that is generated between
the primary cluster and the replication (remote) cluster or AZ by replication
schedules. This encryption feature does not include or consider encryption of the
traffic flowing between Prism Element and Prism Central.
Note:
This
feature only supports the use of native keys and certificates and does not support
custom, user-provided keys and certificates to encrypt the replication
traffic.
For details about the ports and protocols used by encrypted replication traffic, see
Ports and Protocols.
Enabling Encryption of Replication Traffic
Before you begin
For encryption of
Leap-based
DR replication traffic, ensure that
Leap-based
DR is set up and the two AZs (AZs) are paired. This requirement is not applicable to
protection domain based DR.
About this task
For details about the ports and protocols used by encrypted replication traffic, see
Ports and Protocols.
To enable encryption of replication traffic, perform the following steps on the
primary and replication (remote) clusters.
Important:
For encryption of
Leap based DR replication traffic also, you must perform these steps of the
clusters in primary and replication AZs. Also, ensure that the Prism Centrals of
the two AZs are paired.
Important:
Enter the password for the
nutanix
access for the remote cluster CVM when prompted.
nutanix@CVM:~/bin$ python onwire_encryption_tool.py --leap --enable 10.xxx.xxx.xxx
Checking Source Cluster Compatibility
Check Complete. Source is compatible
Checking Remote cluster Compatibility
nutanix@10.xxx.xxx.xxx's password:
Check Complete. Remote cluster is compatible
Importing root.crt from Remote Cluster: 10.xxx.xxx.xxx
nutanix@10.xxx.xxx.xxx's password:
Checking if Remote Cluster's root.crt file already exists
nutanix@10.xxx.xxx.xxx's password:
Encryption enabled Successfully. Please perform rolling restart of Cerebro and Stargate services for changes to take effect
What to do next
Ensure that the changes take effect by performing a rolling restart of Cerebro and
Stargate services on the primary and replication clusters using the following
command.
Important:
Enter the password for the
nutanix
access for the remote cluster CVM when prompted.
nutanix@CVM:~/bin$ python onwire_encryption_tool.py --leap --disable 10.xxx.xxx.xxx
Checking Source Cluster Compatibility
Stopping Cerebro on all nodes of the cluster
Encryption disabled Successfully. Please perform rolling restart of Cerebro and Stargate services for changes to take effect.
What to do next
Ensure that the changes take effect by performing a rolling restart of Cerebro and
Stargate services on the primary and replication clusters using the following
command.
Protection and DR between On-Prem AZs (Nutanix Disaster Recovery)
Leap protects your guest VMs and orchestrates their disaster recovery (DR) to other Nutanix
clusters when events causing service disruption occur at the primary AZ. For protection of
your guest VMs, protection policies with Asynchronous, NearSync, or Synchronous replication
schedules generate and replicate recovery points to other on-prem AZs (AZs). Recovery plans
orchestrate DR from the replicated recovery points to other Nutanix clusters at the same or
different on-prem AZs.
Protection policies create a recovery point—and set its expiry time—in every iteration of the
specified time period (RPO). For example, the policy creates a recovery point every 1 hour for
an RPO schedule of 1 hour. The recovery point expires at its designated expiry time based on
the retention policy—see step 3 in Creating a Protection Policy with an Asynchronous Replication Schedule (Nutanix Disaster Recovery). If there is a prolonged
outage at an AZ, the Nutanix cluster retains the last recovery point to ensure you do not lose
all the recovery points. For NearSync replication (lightweight snapshot), the Nutanix cluster
retains the last full hourly snapshot. During the outage, the Nutanix cluster does not clean
up the recovery points due to expiry. When the Nutanix cluster comes online, it cleans up the
recovery points that are past expiry immediately.
For High Availability of a guest VM,
Nutanix Disaster Recovery
enables replication of its recovery points to one or more on-prem AZs. A protection policy can
replicate recovery points to maximum two on-prem AZs. For replication, you must add a
replication schedule between AZs. You can set up the on-prem AZs for protection and DR in the
following arrangements.
Figure.
The Primary and recovery Nutanix clusters at the different on-prem AZs
Click to enlarge
Figure.
The Primary and recovery Nutanix clusters at the same on-prem AZ
Click to enlarge
The replication to multiple AZs enables DR to Nutanix clusters at all the AZs where the
recovery points replicate or exist. To enable performing DR to a Nutanix cluster at the same
or different AZ (recovery AZ), you must create a recovery plan. To enable performing DR to
two different Nutanix clusters at the same or different recovery AZs, you must create two
discrete recovery plans—one for each recovery AZ. In addition to performing DR to Nutanix
clusters running the same hypervisor type, you can also perform cross-hypervisor disaster
recovery (CHDR)—DR from AHV clusters to ESXi clusters, or from ESXi clusters to AHV
clusters.
The protection policies and recovery plans you create or update synchronize continuously
between the primary and recovery on-prem AZs. The reverse synchronization enables you to
create or update entities (protection policies, recovery plans, and guest VMs) at either the
primary or the recovery AZs.
The following section describes protection of your guest VMs and DR to a Nutanix cluster at
the same or different on-prem AZs. The workflow is the same for protection and DR to a
Nutanix cluster in supported public cloud platforms. For information about protection of your
guest VMs and DR from Xi Cloud Services to an on-prem Nutanix cluster (Xi Leap), see Protection and DR between On-Prem AZ and Xi Cloud Service (Xi Leap).
Nutanix Disaster Recovery Requirements
The following are the general requirements of
Nutanix Disaster Recovery
. Along with the general requirements, there are
specific requirements for protection with the following supported replication
schedules.
For information about the on-prem node, disk and Foundation configurations required to
support Asynchronous, NearSync, and Synchronous replication schedules, see On-Prem Hardware Resource Requirements.
For specific requirements of protection with Asynchronous replication schedule (1 hour
or greater RPO), see Asynchronous Replication Requirements (Nutanix Disaster Recovery).
For specific requirements of protection with NearSync replication schedule (1–15 minutes
RPO), see NearSync Replication Requirements (Nutanix Disaster Recovery).
For specific requirements of protection with Synchronous replication schedule (0 RPO),
see Synchronous Replication Requirements.
License Requirements
The AOS license required depends on the features that you want to use. For information
about the features that are available with an AOS license, see Software Options.
Hypervisor Requirements
The underlying hypervisors required differ in all the supported replication schedules. For
more information about underlying hypervisor requirements for the supported replication
schedules, see:
Each on-prem AZ (AZ) must have a Leap enabled Prism Central instance.
To enable Leap in Prism Central, see Enabling Nutanix Disaster Recovery for On-Prem AZ.
Note:
If you are using ESXi, register at least one vCenter Server to Prism Central.
You can also register two vCenter Servers, each to a Prism Central at different AZs.
If you register both the Prism Central to the single vCenter Server, ensure that each
ESXi cluster is part of different datacenter object in vCenter.
The primary and recovery Prism Central and Prism Element on the Nutanix clusters must be
running on the supported AOS versions. For more information about the required versions
for the supported replication schedules, see:
Nutanix supports replications between the all the latest supported LTS
and STS released AOS versions. To check the list of the latest supported
AOS versions, see KB-5505. To determine if the
AOS versions currently running on your clusters are EOL, see the EOL document .
Upgrade the AOS version to the next available supported LTS/STS release.
To determine if an upgrade path is supported, check the Upgrade Paths page before you upgrade the
AOS.
Note:
If both clusters have different AOS versions that are EOL, upgrade
the cluster with lower AOS version to match the cluster with higher
AOS version and then perform the upgrade to the next supported LTS
version.
For example, the clusters are running AOS versions 5.5.x and 5.10.x
respectively. Upgrade the cluster on 5.5.x to 5.10.x. After both the
clusters are on 5.10.x, proceed to upgrade each cluster to 5.15.x
(supported LTS). Once both clusters are on 5.15.x you can upgrade the
clusters to 5.20.x or newer.
Nutanix recommends that both the primary and the replication clusters or
AZs run the same AOS version.
User Requirements
You must have one of the following roles in Prism Central.
User admin
Prism Central admin
Prism Self Service admin
Xi admin
To view the available roles or create a role, click the hamburger icon at the top-left
corner of the window and go to
Administration
>
Roles
in the left pane.
Firewall Port Requirements
To allow two-way replication between Nutanix clusters at the same or different AZs, you
must enable certain ports in your external firewall. To know about the required ports, see
Disaster Recovery - Leap
in Port Reference.
Networking Requirements
Requirements for static IP address preservation after failover
You can preserve one IP address of a guest VM (with static IP address) for its
failover (DR) to an IPAM network. After the failover, the other IP addresses of the
guest VM have to be reconfigured manually. To preserve an IP address of a guest VM (with
static IP address), ensure that:
Caution:
By default, you cannot preserve statically assigned DNS IP
addresses after failover (DR) of guest VMs. However, you can create custom in-guest
scripts to preserve the statically assigned DNS IP addresses. For more information,
see Creating a Recovery Plan (Nutanix Disaster Recovery).
Both the primary and the recovery Nutanix clusters run AOS 5.11 or newer.
The protected guest VMs have Nutanix Guest Tools (NGT) version 1.5 or newer
installed.
For information about installing NGT, see Nutanix Guest Tools in
Prism Web
Console Guide
.
The protected guest VMs have at least one empty CD-ROM slot.
The empty CD-ROM
is required for mounting NGT at the recovery AZ.
The protected guest VMs can reach the Controller VM from both the AZs.
The protected guest VMs have NetworkManager command-line tool (nmcli) version
0.9.10.0 or newer installed.
Also, the NetworkManager must manage the networks on
Linux VMs. To enable NetworkManager on a Linux VM, in the interface configuration
file, set the value of the
NM_CONTROLLED
field to
yes
. After setting the field, restart the network service on
the VM.
Tip:
In CentOS, the interface configuration file is
/etc/sysconfig/network-scripts/ifcfg-eth0
.
Requirements for static IP address mapping of guest VMs between source and target
virtual networks
You can explicitly define IP addresses for guest VMs that have static IP addresses on
the primary AZ. On recovery, such guest VMs retain the explicitly defined IP address.
To map static IP addresses of guest VMs between source and target virtual networks,
ensure that:
Both the primary and the recovery Nutanix clusters run AOS 5.17 or newer.
The protected guest VMs have static IP addresses at the primary AZ.
The protected guest VMs have Nutanix Guest Tools (NGT) version 1.5 or newer
installed.
For information about installing NGT, see Nutanix Guest Tools in
Prism Web
Console Guide
.
The protected guest VMs have at least one empty CD-ROM slot.
The empty CD-ROM
is required for mounting NGT at the recovery AZ.
The protected guest VMs can reach the Controller VM from both the AZs.
The recovery plan selected for failover has VM-level IP address mapping
configured.
Virtual network design requirements
You can design the virtual subnets that you plan to use for DR to the recovery AZ so
that they can accommodate the guest VMs running in the source virtual network.
Maintain a uniform network configuration for all the virtual LANs (VLANs) with the
same VLAN ID and network range in all the Nutanix clusters at a AZ. All such VLANs
must have the same subnet name, IP address range, and IP address prefix length
(
(Gateway IP/Prefix Length)
).
For example, if you have
VLAN with id 0 and network 10.45.128.0/17, and three clusters PE1, PE2, and PE3 at
the AZ AZ1, all the clusters must maintain the same name, IP address range, and
IP address prefix length (
(Gateway IP/Prefix Length)
), for
VLAN with id 0.
To use a virtual network as a recovery virtual network, ensure that the virtual
network meets the following requirements.
The network prefix is the same as the network prefix of the source virtual
network. For example, if the source network address is 192.0.2.0/24, the network
prefix of the recovery virtual network must also be 24.
The gateway IP address is the same as the gateway IP address in the source
network. For example, if the gateway IP address in the source virtual network
192.0.2.0/24 is 192.0.2.10, the last octet of the gateway IP address in the
recovery virtual network must also be 10.
To use a single Nutanix cluster as a target for DR from multiple primary Nutanix
clusters, ensure that the number of virtual networks on the recovery cluster is
equal to the sum of the number of virtual networks on the individual primary Nutanix
clusters. For example, if there are two primary Nutanix clusters, with one cluster
having
m
networks and the other cluster having
n
networks, ensure that the recovery cluster has
m + n
networks. Such
a design ensures that all recovered VMs attach to a network.
Additional Requirements
Both the primary and recovery Nutanix clusters must have an external IP address.
Both the primary and recovery Prism Centrals and Nutanix clusters must have a data
services IP address.
The Nutanix cluster that hosts the Prism Central must meet the following requirements.
The Nutanix cluster must be registered to the Prism Central instance.
The Nutanix cluster must have an iSCSI data services IP address configured on
it.
The Nutanix cluster must also have sufficient memory to support a hot add of memory
to all Prism Central nodes when you enable Leap. A small Prism Central instance (4
vCPUs, 16 GB memory) requires a hot add of 4 GB, and a large Prism Central instance (8
vCPUs, 32 GB memory) requires a hot add of 8 GB. If you enable Nutanix Flow, each
Prism Central instance requires an extra hot-add of 1 GB.
Each node in a scaled-out Prism Central instance must have a minimum of 4 vCPUs and 16
GB memory.
For more information about the scaled-out deployments of a Prism Central,
see Nutanix Disaster Recovery Terminology.
The protected guest VMs must have Nutanix VM mobility drivers installed.
Nutanix VM
mobility drivers are required for accessing the guest VMs after failover. Without
Nutanix VM mobility drivers, the guest VMs become inaccessible after a
failover.
Maintain a uniform network configuration for all the virtual LANs (VLANs) with the same
VLAN ID and network range in all the clusters at an AZ (AZ). All such
VLANs must have the same subnet name, IP address range, and IP address prefix length
(
(Gateway IP/Prefix Length)
).
For example, if you have VLAN
with id 0 and network 10.45.128.0/17, and three clusters PE1, PE2, and PE3 at the AZ
AZ1, all the clusters must maintain the same name, IP address range, and IP address
prefix length (
(Gateway IP/Prefix Length)
), for VLAN with id
0.
Nutanix Disaster Recovery Limitations
Consider the following general limitations before configuring
Nutanix Disaster Recovery
. Along with the general limitations, there are
specific protection limitations with the following supported replication schedules.
For specific limitations of protection with Asynchronous replication schedule (1 hour or
greater RPO), see Asynchronous Replication Limitations (Nutanix Disaster Recovery).
For specific limitations of protection with NearSync replication schedule (1–15 minutes
RPO), see NearSync Replication Limitations (Nutanix Disaster Recovery).
For specific limitations of protection with Synchronous replication schedule (0 RPO),
see Synchronous Replication Limitations.
Virtual Machine Limitations
You cannot do or implement the following.
Deploy witness VMs.
Protect multiple guest VMs that use disk sharing (for example, multi-writer sharing,
Microsoft Failover Clusters, Oracle RAC).
When you perform DR of vGPU
console-enabled guest VMs, the VMs recover with the default VGA console (without any
alert) instead of vGPU console. The guest VMs fail to recover when you perform
cross-hypervisor disaster recovery (CHDR). For more information about DR and backup
behavior of guest VMs with vGPU, see vGPU Enabled Guest VMs.
Configure NICs for a guest VM across both the virtual private clouds (VPC).
You can
configure NICs for a guest VM associated with either production or test VPC.
Volume Groups Limitation
You cannot protect volume groups.
Network Segmentation Limitation
You cannot apply network segmentation for management traffic (any traffic not on the
backplane network) in Leap.
You get an error when you try to enable network segmentation for management traffic on a
Leap enabled Nutanix Cluster or enable Leap in a network segmentation enabled Nutanix
cluster. For more information about network segmentation, see Securing Traffic Through Network Segmentation in the
Security Guide
.
Note:
However, you can apply network
segmentation for backplane traffic at the primary and recovery clusters. Nutanix does not
recommend this because when you perform a planned failover of guest VMs having network
segmentation for backplane enabled, the guest VMs fail to recover and the guest VMs at the
primary AZ are removed.
Virtual Network Limitation
Although there is no limit to the number of VLANs that you can create, only the first 500
VLANs list in the drop-down of
Network Settings
while creating a
recovery plan. For more information about VLANs in the recovery plan, see Nutanix Virtual Networks.
Nutanix to vSphere Cluster Mapping Limitation
Due to the way the Nutanix architecture distributes data, there is limited support for
mapping a Nutanix cluster to multiple vSphere clusters. If a Nutanix cluster is split into
multiple vSphere clusters, migrate and recovery operations fail.
Failover Limitation
After the failover, the recovered guest VMs do not retain their associated labels.
Tip:
Assign categories to the guest VMs instead of labels because VM categories are
retained after the failover.
vGPU Enabled Guest VMs
The following table list the behavior of guest VMs with vGPU to disaster recovery (DR)
and backup deployments.
Table 1.
Primary cluster
Recovery cluster
DR or Backup
Identical vGPU models
Unidentical vGPU models or no vGPU
AHV
AHV
Nutanix Disaster Recovery
Supported:
Recovery point
creation
Replication
Restore
Migrate
VM start
Failover and Failback
Supported:
Recovery point
creation
Replication
Restore
Migrate
Unsupported:
VM start
Failover and Failback
Note:
Only for Synchronous
replication, protection of guest VMs fail.
Backup: HYCU
Guest VMs with vGPU fail to recover.
Guest VMs with vGPU fail to recover.
Backup: Veeam
Guest VMs with vGPU fail to recover.
Guest VMs with vGPU recover but with older vGPU.
Guest VMs with vGPU recover but do not start.
Tip:
The VMs start when you disable vGPU on the guest VM
ESXi
ESXi
Nutanix Disaster Recovery
Guest VMs with vGPU cannot be protected.
Guest VMs with vGPU cannot be protected.
Backup
Guest VMs with vGPU cannot be protected.
Guest VMs with vGPU cannot be protected.
AHV
ESXi
Nutanix Disaster Recovery
vGPU is disabled after failover of Guest VMs with vGPU.
vGPU is disabled after failover of Guest VMs with vGPU.
ESXi
AHV
Nutanix Disaster Recovery
Guest VMs with vGPU cannot be protected.
Guest VMs with vGPU cannot be protected.
Nutanix Disaster Recovery Configuration Maximums
For the maximum number of entities you can configure with different replication schedules
and perform failover (disaster recovery), see Nutanix Configuration Maximums. The limits have been
tested for Leap production deployments. Nutanix does not guarantee the system to be able to
operate beyond these limits.
Tip:
Upgrade your NCC version to 3.10.1 to get configuration alerts.
Nutanix Disaster Recovery Recommendations
Nutanix recommends the following best practices for configuring
Nutanix Disaster Recovery
.
General Recommendations
Create all entities (protection policies, recovery plans, and VM categories) at the
primary AZ (AZ).
Upgrade Prism Central before upgrading Prism Element on the Nutanix clusters registered
to it. For more information about upgrading Prism Central, see Upgrading Prism Central in the
Acropolis
Upgrade Guide
.
Do not include the guest VMs protected
with Asynchronous, NearSync, and Synchronous replication schedules in the
same recovery plan. You can include guest VMs protected with Asynchronous or
NearSync replication schedules in the same recovery plan. However, if you
combine these guest VMs with the guest VMs protected by Synchronous
replication schedules in a recovery plan, the recovery fails.
Disable Synchronous replication before unpairing the AZs.
If you unpair the AZs
while the guest VMs in the Nutanix clusters are still in synchronization, the Nutanix
cluster becomes unstable. For more information about disabling Synchronous replication,
see Synchronous Replication Management.
Recommendation for Migrating Protection Domains to Protection Policies
You can protect a guest VM either with the legacy DR solution (protection domain-based) or
with Leap. To protect a legacy DR-protected guest VM with Leap, you must migrate the guest
VM from the protection domain to a protection policy. During the migration, do not delete
the guest VM snapshots in the protection domain. Nutanix recommends keeping the guest VM
snapshots in the protection domain until the first recovery point for the guest VM is
available on Prism Central. For more information, see Migrating Guest VMs from a Protection Domain to a Protection Policy.
Recommendation for DR to Nutanix Clusters at the Same On-Prem AZ
If the single Prism Central that you use for protection and DR to Nutanix clusters at the
same AZ (AZ) becomes inactive, you cannot perform a failover when required.
To avoid the single point of failure in such deployments, Nutanix recommends installing the
single Prism Central at a different AZ (different fault domain).
Recommendation for Virtual Networks
Map the networks while creating a recovery plan in Prism Central.
Recovery plans do not support overlapping subnets in a network-mapping configuration. Do
not create virtual networks that have the same name or overlapping IP address ranges.
Recommendation for Container Mapping
Create storage containers with the same name on both the primary and recovery Nutanix
clusters.
Leap automatically maps the storage containers during the first replication (seeding) of a
guest VM. If a storage container with the same name exists on both the primary and recovery
Nutanix clusters, the recovery points replicate to the storage container with the same name
only. For example, if your protected guest VMs are in the
SelfServiceContainer
on the primary Nutanix cluster, and the recovery Nutanix cluster also has
SelfServiceContainer
, the recovery points replicate to
SelfServiceContainer
only. If a storage container with the same name does not
exist at the recovery AZ, the recovery points replicate to a random storage container at the
recovery AZ. For more information about creating storage containers on the Nutanix clusters,
see Creating a Storage Container in
Prism Web
Console Guide
.
Nutanix Disaster Recovery
enables protection of your guest VMs
and disaster recovery (DR) to one or more Nutanix clusters at the same or different on-prem AZs.
A Nutanix cluster is essentially an AHV or an ESXi cluster running AOS. In addition to
performing DR to Nutanix clusters running the same hypervisor type, you can also perform
cross-hypervisor disaster recovery (CHDR)—DR from AHV clusters to ESXi clusters, or from ESXi
clusters to AHV clusters.
Leap supports DR (and CHDR) to maximum two different Nutanix clusters at the same or
different AZs (AZs). You can protect your guest VMs with the following
replication schedules.
Asynchronous replication schedule (1 hour or greater RPO). For information about
protection with Asynchronous replication schedule, see Protection with Asynchronous Replication Schedule and DR (Nutanix Disaster Recovery).
NearSync replication schedule (1–15 minute RPO). For information about protection with
NearSync replication schedule, see Protection with NearSync Replication Schedule and DR (Nutanix Disaster Recovery).
Synchronous replication schedule (0 RPO). For information about protection with
Synchronous replication schedule, see Protection with Synchronous Replication Schedule (0 RPO) and DR.
To maintain the
efficiency in protection and DR, Leap allows to protect a guest VM with Synchronous
replication schedule to only one AHV cluster and at the different on-prem availability
zone.
Nutanix Disaster Recovery Views
The disaster recovery (DR) views enable you to perform CRUD operations on the following
types of Leap entities.
Configured entities (for example, AZs, protection policies, and recovery
plans)
Created entities (for example, guest VMs, and recovery points)
This chapter describes the views of Prism Central (on-prem AZ).
AZs View
The
AZs
view under the
hamburger icon
>
Administration
lists all of your paired AZs.
The following figure is a sample view, and the tables describe the fields and the actions
that you can perform in this view.
Figure.
AZs View
Click to enlarge
Table 1.
AZs View Fields
Field
Description
Name
Name of the AZ.
Region
Region to which the AZ belongs.
Type
Type of AZ. AZs that are backed by on-prem Prism
Central instances are shown to be of type physical. The AZ that you are
logged in to is shown as a local AZ.
Connectivity Status
Status of connectivity between the local AZ and the paired
AZ.
Table 2.
Workflows Available in the AZs View
Workflow
Description
Connect to AZ (on-prem Prism Central only)
Connect to an on-prem Prism Central or to a Xi Cloud Services for data
replication.
Table 3.
Actions Available in the Actions Menu
Action
Description
Disconnect
Disconnect the remote AZ. When you disconnect an availability
zone, the pairing is removed.
Protection Summary View
The
Protection Summary
view under the
hamburger icon
>
Data Protection
shows detailed information about the Leap entities in an AZ (AZ)
and helps you generate DR reports for the specified time. The information in the
Protection Summary
view enables you to monitor the health of your DR
deployments (Leap) and the activities performed on Leap entities. Select a topology in the
left-hand side pane and protection and recovery information of the selected topology shows up in
DR widgets on the right-hand side pane. The following figures are a sample view, and the tables
describe the fields and the actions that you can perform in the DR widgets.
Figure.
Protection Summary: Protected Entities, Replication Tasks, and Recovery
Readiness
Click to enlarge
Figure.
Protection Summary: Configuration Alerts
Click to enlarge
Figure.
Protection Summary: Reports and Recovery Events
Click to enlarge
Table 1.
Protected Entities
Field
Description
Total
Number of guest VMs protected. Clicking the number shows the guest VMs protected
in protection policies.
RPO Not Met
Number of guest VMs that are protected but do not meet the specified RPO.
Clicking the number shows the guest VMs that do not meet the specified RPO.
Table 2.
Replication Tasks
Field
Description
Ongoing
Number of ongoing replication tasks.
Stuck
Number of replication tasks that are stuck. Clicking the number shows the stuck
alerts generated in
Alerts
.
Failed
Number of replication tasks that failed. Clicking the number shows the alerts
generated in
Alerts
.
Table 3.
Recovery Readiness
Field
Description
Measured by
Failover operations to check the readiness of the recovery plans. You can use
Validate
,
Test Failover
, or
Planned Failover
from the drop-down list to check recovery
readiness.
Succeeded
Number of recovery plans on which the selected failover operation ran
successfully. Clicking the number shows the recovery plans on which the selected
failover operation ran successfully.
Succeeded With Warnings
Number of recovery plans on which the selected failover operation ran
successfully but with warnings. Clicking the number shows the recovery plans on which
the selected failover operation ran successfully with warnings.
Failed
Number of recovery plans on which the selected failover operation failed to run
successfully. Clicking the number shows the recovery plans on which the selected
failover operation failed to run successfully.
Not Executed
Number of recovery plans on which no failover operation ran. Clicking the number
shows the recovery plans on which no failover operation ran.
Table 4.
Entities with RPO Not Met
Field
Description
Name
Names of guest VMs that do not meet the specified RPO. You can use the filters on
the guest VMs to investigate the reason for RPO not meeting.
Table 5.
Configuration Alerts
Field
Description
Alert Description
Description of configuration alerts raised on protection policies and recovery
plans.
Impacted Entity
The entities impacted by the configuration alerts.
Table 6.
Reports
Field
Description
Report Name
Name of the report.
Generated at
Date and time when the report was generated.
Download
Option to download the report as a PDF or a CSV document.
Recovery Events
This widget shows you a detailed view of the
Recovery Readiness
. You
can view information about all the recovery plans that ran on the selected AZs in the last
3 months.
Protection Policies View
The
Protection Policies
view under the
hamburger icon
>
Data Protection
lists all of configured protection policies from all the paired availability
zones.
The following figure is a sample view, and the tables describe the fields and the actions
that you can perform in this view.
Figure.
Protection Policies View
Click to enlarge
Table 1.
Protection Policies View Fields
Field
Description
Policy Name
Name of the protection policy.
Schedules
Number of schedules configured in the protection policy. If the protection policy
has multiple schedules, a drop-down icon is displayed. Click the drop-down icon to see
the
primary location:primary Nutanix cluster
,
recovery
location:recovery Nutanix cluster
, and
RPO
of the
schedules in the protection policy.
Alerts
Number of alerts issued for the protection policy.
Table 2.
Workflows Available in the Protection Policies View
Workflow
Description
Create protection policy
Create a protection policy.
Table 3.
Actions Available in the Actions Menu
Action
Description
Update
Update the protection policy.
Clone
Clone the protection policy.
Delete
Delete the protection policy.
Recovery Plans View
The
Recovery Plans
view under the
hamburger icon
>
Data Protection
lists all of configured recovery plans from all the paired availability
zones.
The following figure is a sample view, and the tables describe the fields and the actions
that you can perform in this view.
Figure.
Recovery Plans View
Click to enlarge
Table 1.
Recovery Plans View Fields
Field
Description
Name
Name of the recovery plan.
Primary Location
Replication source AZ for the recovery plan.
Recovery Location
Replication target AZ for the recovery plan.
Entities
Sum of the following VMs:
Number of local, live VMs that are specified in the recovery plan.
Number of remote VMs that the recovery plan can recover at this AZ.
Last Validation Status
Status of the most recent validation of the recovery plan.
Last Test Status
Status of the most recent test performed on the recovery plan.
Last Failover Status
Status of the most recent failover performed on the recovery plan.
Table 2.
Workflows Available in the Recovery Plans View
Workflow
Description
Create Recovery Plan
Create a recovery plan.
Table 3.
Actions Available in the Actions Menu
Action
Description
Validate
Validates the recovery plan to ensure that the VMs in the recovery plan have a
valid configuration and can be recovered.
Test
Tests the recovery plan.
Clean-up test VMs
Cleans up the VMs failed over as a result of testing recovery plan.
Update
Updates the recovery plan.
Failover
Performs a failover.
Delete
Deletes the recovery plan.
VM Recovery Points
The
VM Recovery Points
view under the
hamburger icon
>
Data Protection
lists all the recovery points of all the protected guest VMs (generated over
time).
The following figure is a sample view, and the tables describe the fields and the actions
that you can perform in this view.
Figure.
VM Recovery Points
Click to enlarge
Table 1.
VM Recovery Points View Fields
Field
Description
Name
Name of the recovery point.
Latest Recovery Point on Local AZ
Replication source AZ for the recovery plan.
Oldest Recovery Point on Local AZ
Replication target AZ for the recovery plan.
Total Recovery Points
Number of recovery points generated for the guest VM.
Owner
Owner account of the recovery point.
Table 2.
Actions Available in the Actions Menu
Action
Description
Clone (Previously Restore)
Clones the guest VM from the selected recovery points. The operation creates a
copy of guest VM in the same Nutanix cluster without overwriting the original guest VM
(out-of-place restore). For more information, see Manual Recovery of Guest VMs.
Revert
Reverts the guest VMs to the selected recovery points. The operation recreates
the guest VM in the same Nutanix cluster by overwriting the original guest VM
(in-place restore). For more information, see Manual Recovery of Guest VMs.
Replicate
Manually replicates the selected recovery points to a different Nutanix cluster
in the same or different AZs. For more information, see Replicating Recovery Points Manually.
Dashboard Widgets
The dashboard includes widgets that display the statuses of configured protection
policies and recovery plans. If you have not configured these VMs, the widgets display a summary
of the steps required to get started with Leap.
To view these widgets, click the
Dashboard
tab.
The following figure is a sample view of the dashboard widgets.
Figure.
Dashboard Widgets for Leap
Click to enlarge
Enabling Nutanix Disaster Recovery for On-Prem AZ
To perform disaster recovery (DR) to Nutanix clusters at different on-prem available
zones (AZs), enable Leap at both the primary and recovery AZs (Prism Central). Without
enabling Leap, you can configure protection policies and recovery plans that synchronize to
the paired AZs but you cannot perform failover and failback operations. To perform DR to
different Nutanix clusters at the same AZ, enable Leap in the single Prism
Central.
About this task
To enable
Nutanix Disaster Recovery
, perform the following
procedure.
Note:
You cannot disable
Nutanix Disaster Recovery
once you have enabled it.
Procedure
Log on to the Prism Central web console.
Click the settings button (gear icon) at the top-right corner of the
window.
Click
Enable Leap
in the
Setup
section on the left pane.
Figure.
Enabling Leap
Click to enlarge
The
Leap
dialog box run prechecks. If any
precheck fails, resolve the issue that is causing the failure and click
check again
.
Click
Enable
after all the prechecks pass.
Leap is enabled after at least 10 seconds.
Pairing AZs (Nutanix Disaster Recovery)
To replicate entities (protection policies, recovery plans, and recovery points) to
different on-prem AZs (AZs) bidirectionally, pair the AZs with each
other. To replicate entities to different Nutanix clusters at the same AZ bidirectionally,
you need not pair the AZs because the primary and the recovery Nutanix clusters are
registered to the same AZ (Prism Central). Without pairing the AZs, you cannot perform
DR to a different AZ.
About this task
To pair an on-prem AZ with another on-prem AZ, perform the following procedure at
either of the on-prem AZs.
Procedure
Log on to the Prism Central web console.
Click the hamburger icon at the top-left corner of the window. Go to
Administration
>
AZs
in the left pane.
Figure.
Pairing AZ
Click to enlarge
Click
Connect to AZ
.
Specify the following information in the
Connect to Availability
Zone
window.
Figure.
Connect to AZ
Click to enlarge
AZ Type
: Select
Physical Location
from the drop-down
list.
A physical location is an on-prem AZ (AZ). To pair
the on-prem AZ with Xi Cloud Services, select
XI
from the drop-down list, and enter the
credentials of your Xi Cloud Services account in step c and set
d.
IP Address for Remote PC
: Enter the IP address
of the recovery AZ Prism Central.
Username
: Enter the username of your recovery
AZ Prism Central.
Password
: Enter the password of your recovery
AZ Prism Central.
Click
Connect
.
Both the on-prem AZs are paired to each other.
Protection and Automated DR (Nutanix Disaster Recovery)
Automated disaster recovery (DR) configurations use protection policies to protect your guest
VMs, and recovery plans to orchestrate the recovery of those guest VMs to different Nutanix
clusters at the same or different AZs (AZs). You can automate protection of your guest VMs
with the following supported replication schedules in
Nutanix Disaster Recovery
.
Asynchronous replication schedule (1 hour or greater RPO). For information about
protection with Asynchronous replication schedule, see Protection with Asynchronous Replication Schedule and DR (Nutanix Disaster Recovery).
NearSync replication schedule (1–15 minute RPO). For information about protection with
NearSync replication schedule, see Protection with NearSync Replication Schedule and DR (Nutanix Disaster Recovery).
Synchronous replication schedule (0 RPO). For information about protection with
Synchronous replication schedule, see Protection with Synchronous Replication Schedule (0 RPO) and DR.
To maintain the
efficiency in protection and DR, Leap allows to protect a guest VM with Synchronous
replication schedule to only one AHV cluster and at the different on-prem availability
zone.
Protection with Asynchronous Replication Schedule and DR (Nutanix Disaster Recovery)
Asynchronous replication schedules enable you to protect your guest VMs with an RPO of 1 hour
or beyond. A protection policy with an Asynchronous replication schedule creates a recovery
point in an hourly time interval, and replicates it to the recovery AZs (AZs)
for High Availability. For guest VMs protected with Asynchronous replication schedule, you can
perform disaster recovery (DR) to different Nutanix clusters at same or different AZs. In
addition to performing DR to Nutanix clusters running the same hypervisor type, you can also
perform cross-hypervisor disaster recovery (CHDR)—DR from AHV clusters to ESXi clusters, or
from ESXi clusters to AHV clusters.
Note:
Nutanix provides multiple DR solutions to protect your environment. See Nutanix Disaster Recovery Solutions for the detailed representation of the DR offerings
of Nutanix.
The following are the specific requirements for protecting your guest VMs with
Asynchronous replication schedule. Ensure that you meet the following requirements in addition
to the general requirements of
Nutanix Disaster Recovery
.
For information about the general requirements of
Nutanix Disaster Recovery
, see Nutanix Disaster Recovery Requirements.
For information about node, disk and Foundation configurations required to support
Asynchronous replication schedules, see On-Prem Hardware Resource Requirements.
Hypervisor Requirements
AHV or ESXi
The AHV clusters must be running on AHV versions that come bundled with the supported
version of AOS.
The ESXi clusters must be running on version ESXi 6.5 GA or newer.
Nutanix Software Requirements
Each on-prem AZ must have a
Nutanix Disaster Recovery
enabled Prism
Central instance.
The primary and recovery Prism Central and Prism Element on the Nutanix clusters must be
running the following versions of AOS.
AHV clusters
AOS 5.17 or newer for DR to different Nutanix clusters at the same AZ.
AOS 5.10 or newer for DR to Nutanix clusters at the different AZs.
ESXi clusters
AOS 5.17 or newer for DR to different Nutanix clusters at the same AZ.
AOS 5.11 or newer for DR to Nutanix clusters at the different AZs.
Guest VMs protected with Asynchronous replication schedule support cross-hypervisor
disaster recovery. You can perform failover (DR) to recover guest VMs from AHV clusters to
ESXi clusters or guest VMs from ESXi clusters to AHV clusters by considering the following
requirements.
Both the primary and the recovery Nutanix clusters must be running AOS 5.17 or newer for
CHDR to Nutanix clusters at the same AZ.
Both the primary and the recovery Nutanix clusters must be running AOS 5.11.2 or newer
for CHDR to Nutanix clusters at different AZs.
Install and configure Nutanix Guest Tools (NGT) on all the guest VMs. For more
information, see Enabling and Mounting Nutanix Guest Tools in
Prism Web Console Guide
.
NGT configures the guest VMs with all the
required drivers for VM portability. For more information about general NGT
requirements, see Nutanix Guest Tools Requirements and Limitations
in
Prism Web Console Guide
.
CHDR supports guest VMs with flat files only.
CHDR supports IDE/SCSI and SATA disks only.
For all the non-boot SCSI disks of Windows guest VMs, set the SAN policy to
OnlineAll
so that they come online automatically.
In vSphere 6.7, guest VMs are configured with UEFI secure boot by default. Upon CHDR to
an AHV cluster, these guest VMs do not start if the host does not support the UEFI secure
boot feature. For more information about supportability of UEFI secure boot on Nutanix
clusters, see Compatibility Matrix.
For information about operating systems that support UEFI and Secure Boot, see UEFI and Secure Boot Support for CHDR.
Nutanix does not support vSphere inventory mapping (for example, VM folder and resource
pools) when protecting workloads between VMware clusters.
Nutanix does not support vSphere snapshots or delta disk files.
If you have delta
disks attached to a guest VM and you proceed with failover, you get a validation warning
and the guest VM does not recover. Contact Nutanix Support for assistance.
Table 1.
Operating Systems Supported for CHDR (Asynchronous Replication)
Operating System
Version
Requirements and limitations
Windows
Windows 2008 R2 or newer versions
Windows 7 or newer versions
Only 64-bit operating systems are supported.
Linux
CentOS 6.5 and 7.0
RHEL 6.5 or newer and RHEL 7.0 or newer.
Oracle Linux 6.5 and 7.0
Ubuntu 14.04
SLES operating system is not supported.
Additional Requirement
The storage container name of the protected guest VMs must be the same on both the primary
and recovery clusters. Therefore, a storage container must exist on the recovery cluster
with the same name as the one on the primary cluster. For example, if the protected VMs are
in the
SelfServiceContainer
storage container on the primary cluster, there
must also be a
SelfServiceContainer
storage container on the recovery
cluster.
Consider the following specific limitations before protecting your guest VMs with
Asynchronous replication schedule. These limitations are in addition to the general limitations
of
Nutanix Disaster Recovery
.
For information about the general limitations of Leap, see Nutanix Disaster Recovery Limitations.
You cannot restore guest VMs with incompatible GPUs at the recovery Nutanix
cluster.
You cannot protect guest VMs configured as part of a network function chain.
You cannot retain hypervisor-specific properties after cross hypervisor disaster
recovery (CHDR).
CHDR does not preserve hypervisor-specific properties (for example,
multi-writer flags, independent persistent and non-persistent disks, changed block
tracking (CBT), PVSCSI disk configurations).
Creating a Protection Policy with an Asynchronous Replication Schedule (Nutanix Disaster Recovery)
To protect the guest VMs in an hourly replication schedule, configure an Asynchronous
replication schedule while creating the protection policy. The policy takes recovery points
of those guest VMs in the specified time intervals (hourly) and replicates them to the
recovery AZs (AZs) for High Availability. To protect the guest VMs at the
same or different recovery AZs, the protection policy allows you to configure Asynchronous
replication schedules to at most two recovery AZs—a unique replication schedule to each
recovery AZ. The policy synchronizes continuously to the recovery AZs in a bidirectional
way.
Before you begin
See Asynchronous Replication Requirements (Nutanix Disaster Recovery) and
Asynchronous Replication Limitations (Nutanix Disaster Recovery) before you
start.
About this task
To create a protection policy with an Asynchronous replication schedule, do the
following at the primary AZ. You can also create a protection policy at the
recovery AZ. Protection policies you create or update at a recovery AZ
synchronize back to the primary AZ.
Procedure
Log on to the Prism Central web console.
Click the hamburger icon at the top-left corner of the window. Go to
Policies
>
Protection Policies
in the left pane.
Figure.
Protection Policy Configuration: Protection Policies
Click to enlarge
Click
Create Protection Policy
.
Specify the following information in the
Create Protection
Policy
window.
Figure.
Protection Policy Configuration: Select Primary Location
Click to enlarge
Policy name
: Enter a name for the protection
policy.
Caution:
The name can be of only alphanumeric, dot, dash,
and underscore characters.
In the
Primary Location
pane, specify the
following information.
Location
: From the drop-down
list, check an AZ that hosts the guests VMs to
protect.
The drop-down lists all the AZs paired
with the local AZ.
Local AZ
represents the local AZ (Prism Central). For your
primary AZ, you can check either the local AZ or a
non-local AZ.
Cluster
: From the drop-down list,
check the Nutanix cluster that hosts the guest VMs to
protect.
The drop-down lists all the Nutanix
clusters registered to Prism Central representing
the selected AZ. If you want to protect the guest
VMs from multiple Nutanix clusters in the same
protection policy, check the clusters that host
those guest VMs.
All Clusters
protects the guest VMs of all Nutanix clusters
registered to Prism Central.
Click
Save
.
Clicking
Save
activates the
Recovery Location
pane.
After saving the primary AZ configuration, you can
optionally add a local schedule (step iv) to retain
the recovery points at the primary AZ.
Click
+ Add Local Schedule
if you
want to retain recovery points locally in addition to
retaining recovery points in a replication schedule
(step d.iv). For example, you can create a local
schedule to retain 15 minute recovery points locally and
also an hourly replication schedule to retain recovery
points and replicate them to a recovery AZ every 2
hours. The two schedules apply differently on the guest
VMs.
Specify the following information in the
Add Schedule
window.
Figure.
Protection Policy Configuration: Add Local
Schedule
Click to enlarge
Take Snapshot Every
:
Specify the frequency in
minutes
,
hours
,
days
, or
weeks
at which you want the
recovery points to be taken locally.
Retention Type
: Specify
one of the following two types of retention policy.
Linear
: Implements a
simple retention scheme at the local AZ. If you
set the retention number to n, the local AZ
retains the n recent recovery points.
When you
enter the frequency in
minutes
, the system selects
the
Roll-up
retention type
by default because minutely recovery points do not
support
Linear
retention
types.
Roll-up
: Rolls up the
recovery points into a single recovery point at
the local AZ.
For more information about the
roll-up recovery points, see step d.iii.
Retention on Local
AZ:PE_A3_AHV
: Specify the retention
number for the local AZ.
If you want to take application-consistent
recovery points, check
Take
App-Consistent Recovery
Point
.
Irrespective of the local or
replication schedules, the recovery points are of
the specified type. If you check
Take
App-Consistent Recovery Point
, the
recovery points generated are
application-consistent and if you do not check
Take App-Consistent Recovery
Point
, the recovery points generated
are crash-consistent. If the time in the local
schedule and the replication schedule match, the
single recovery point generated is
application-consistent.
Note:
See Application-consistent Recovery Point Conditions and Limitations before you take
application-consistent snapshot.
Click
Save Schedule
.
In the
Recovery Location
pane, specify the
following information.
Figure.
Protection Policy Configuration: Select Recovery
Location
Click to enlarge
Location
: From the drop-down
list, select the AZ (AZ) where you want
to replicate the recovery points.
The drop-down lists
all the AZs paired with the local AZ.
Local AZ
represents the local
AZ (Prism Central). Select
Local
AZ
if you want to configure DR to a
different Nutanix cluster at the same AZ.
If
you do not select a AZ, local recovery points that
are created by the protection policy do not
replicate automatically. You can, however, replicate
the recovery points manually and use recovery plans
to recover the guest VMs. For more information, see
Protection and Manual DR (Nutanix Disaster Recovery).
Cluster
: From the drop-down list,
select the Nutanix cluster where you want to replicate
the recovery points.
The drop-down lists all the
Nutanix clusters registered to Prism Central
representing the selected AZ. You can select one
cluster at the recovery AZ. If you want to
replicate the recovery points to more clusters at
the same or different AZs, add another recovery
AZ with a replication schedule. For more
information to add another recovery AZ with a
replication schedule, see step e.
Note:
Selecting
auto-select
from the
drop-down list replicates the recovery points to any
available cluster at the recovery AZ. Select
auto-select
from the
drop-down list only if all the clusters at the
recovery AZ are up and running.
Caution:
If the primary Nutanix cluster
contains an IBM POWER Systems server, you can
replicate recovery points to an on-prem AZ only if
that on-prem AZ contains an IBM Power Systems
server.
Click
Save
.
Clicking
Save
activates the
+ Add Schedule
button
between the primary and the recovery AZ. After
saving the recovery AZ configuration, you can
optionally add a local schedule to retain the
recovery points at the recovery AZ.
Click
+ Add Local Schedule
if you
want to retain recovery points locally in addition to
retaining recovery points in a replication schedule
(step d.iv). For example, you can create a local
schedule to retain one hourly recovery points locally to
supplement the hourly replication schedule. The two
schedules apply differently on the guest VMs after
failover, when the recovery points replicate back to the
primary AZ.
Specify the following information in the
Add Schedule
window.
Figure.
Protection Policy Configuration: Add Local
Schedule
Click to enlarge
Take Snapshot Every
:
Specify the frequency in
minutes
,
hours
,
days
, or
weeks
at which you want the
recovery points to be taken locally.
Retention Type
: Specify
one of the following two types of retention policy.
Linear
: Implements a
simple retention scheme at the local AZ. If you
set the retention number to n, the local AZ
retains the n recent recovery points.
When you
enter the frequency in
minutes
, the system selects
the
Roll-up
retention type
by default because minutely recovery points do not
support
Linear
retention
types.
Roll-up
: Rolls up the
recovery points into a single recovery point at
the local AZ.
For more information about the
roll-up recovery points, see step d.iii.
Retention on
10.xx.xx.xxx:PE_C1_AHV
: Specify the
retention number for the local AZ.
If you want to take application-consistent
recovery points, check
Take
App-Consistent Recovery
Point
.
Irrespective of the local or
replication schedules, the recovery points are of
the specified type. If you check
Take
App-Consistent Recovery Point
, the
recovery points generated are
application-consistent and if you do not check
Take App-Consistent Recovery
Point
, the recovery points generated
are crash-consistent. If the time in the local
schedule and the replication schedule match, the
single recovery point generated is
application-consistent.
Note:
See Application-consistent Recovery Point Conditions and Limitations before you take
application-consistent snapshot.
Click
Save Schedule
.
Click
+ Add Schedule
to add a replication
schedule between the primary and the recovery AZ.
Specify the following information in the
Add
Schedule
window. The window auto-populates the
Primary Location
and
Recovery
Location
that you have selected in step b and step
c.
Figure.
Protection Policy Configuration: Add Schedule
(Asynchronous)
Click to enlarge
Protection Type
: Click
Asynchronous
.
Take Snapshot Every
: Specify the
frequency in
hours
,
days
, or
weeks
at which you want the
recovery points to be taken.
The specified frequency
is the RPO. For more information about RPO, see
Nutanix Disaster Recovery Terminology.
Retention Type
: Specify one of
the following two types of retention policy.
Linear
: Implements a
simple retention scheme at both the primary
(local) and the recovery (remote) AZ. If you set
the retention number for a given AZ to n, that
AZ retains the n recent recovery points. For
example, if the RPO is 1 hour, and the retention
number for the local AZ is 48, the local AZ
retains 48 hours (48 X 1 hour) of recovery points
at any given time.
Tip:
Use linear
retention policies for small RPO windows with
shorter retention periods or in cases where you
always want to recover to a specific RPO
window.
Roll-up
: Rolls up the
recovery points as per the RPO and retention
period into a single recovery point at a AZ. For
example, if you set the RPO to 1 hour, and the
retention time to 5 days, the 24 oldest hourly
recovery points roll up into a single daily
recovery point (one recovery point = 24 hourly
recovery points) after every 24 hours. The system
keeps one day (of rolled-up hourly recovery
points) and 4 days of daily recovery points.
Note:
If the retention period is n days, the system
keeps 1 day of RPO (rolled-up hourly recovery
points) and n-1 days of daily recovery
points.
If the retention period is n weeks, the system
keeps 1 day of RPO, 1 week of daily and n-1 weeks
of weekly recovery points.
If the retention period is n months, the
system keeps 1 day of RPO, 1 week of daily, 1
month of weekly, and n-1 months of monthly
recovery points.
If the retention period is n years, the system
keeps 1 day of RPO, 1 week of daily, 1 month of
weekly, and n-1 months of monthly recovery
points.
Note:
The recovery points that are used to
create a rolled-up recovery point are
discarded.
Tip:
Use roll-up
retention policies for anything with a longer
retention period. Roll-up policies are more
flexible and automatically handle recovery point
aging/pruning while still providing granular RPOs
for the first day.
To specify the retention number for the primary and
recovery AZs, do the following.
Retention on Local AZ:
PE_A3_AHV
: Specify the retention
number for the primary AZ.
This field is
unavailable if you do not specify a recovery
location.
Retention on
10.xx.xx.xxx:PE_C1_AHV
: Specify the
retention number for the recovery AZ.
If you
select linear retention, the remote and local
retention count represents the number of recovery
points to retain at any given time. If you select
roll-up retention, these numbers specify the
retention period.
If you want to enable reverse retention of the recovery
points, check
Reverse retention for VMs on
recovery
location
.
Note:
Reverse
retention for VMs on recovery location
is available only when the retention numbers on the
primary and recovery AZs are
different.
Reverse retention maintains the
retention numbers of recovery points even after
failover to a recovery AZ in the same or different
AZs. For example, if you retain two
recovery points at the primary AZ and three
recovery points at the recovery AZ, and you enable
reverse retention, a failover event does not change
the initial retention numbers when the recovery
points replicate back to the primary AZ. The
recovery AZ still retains two recovery points
while the primary AZ retains three recovery
points. If you do not enable reverse retention, a
failover event changes the initial retention numbers
when the recovery points replicate back to the
primary AZ. The recovery AZ retains three
recovery points while the primary AZ retains two
recovery points.
Maintaining the same
retention numbers at a recovery AZ is required if
you want to retain a particular number of recovery
points, irrespective of where the guest VM is after
its failover.
If you want to take application-consistent recovery
points, check
Take App-Consistent Recovery
Point
.
Application-consistent recovery
points ensure that application consistency is
maintained in the replicated recovery points. For
application-consistent recovery points, install NGT
on the guest VMs running on AHV clusters. For guest
VMs running on ESXi clusters, you can take
application-consistent recovery points without
installing NGT, but the recovery points are
hypervisor-based, and leads to VM stuns (temporary
unresponsive VMs) after failover to the recovery
AZs.
Note:
See Application-consistent Recovery Point Conditions and Limitations before you take
application-consistent snapshot.
Caution:
Application-consistent
recovery points fail for EFI-boot enabled Windows
2019 VM running on ESXi when NGT is not installed.
Nutanix recommends installing NGT on guest VMs
running on ESXi also.
Click
Save Schedule
.
Click
+ Add Recovery Location
at the top-right
if you want to add an additional recovery AZ for the guest VMs in the
protection policy.
To add an on-prem AZ for recovery, see Protection and DR between On-Prem AZs (Nutanix Disaster Recovery)
To add Xi Cloud Services for recovery, see Protection and DR between On-Prem AZ and Xi Cloud Service (Xi Leap).
Figure.
Protection Policy Configuration: Additional Recovery
Location
Click to enlarge
Click
+ Add Schedule
to add a replication
schedule between the primary AZ and the additional recovery AZ you
specified in step e.
Perform step d again in the
Add Schedule
window
to add the replication schedule. The window auto-populates the
Primary Location
and the additional
Recovery Location
that you have selected in
step b and step c.
By default, recovery point creation begins immediately after you
create the protection policy. If you want to specify when recovery
point creation must begin, click
Immediately
at the top-right corner, and then, in the
Start
Time
dialog box, do the following.
Click
Start protection at specific point in
time
.
Specify the time at which you want to start taking
recovery points.
Click
Save
.
Click
Next
.
Clicking
Next
shows a list of VM categories
where you can optionally check one or more VM categories to protect in
the protection policy. DR configurations using Leap allows you to
protect a guest VM by using only one protection policy. Therefore, VM
categories specified in another protection policy are not in the list.
If you protect a guest VM in another protection policy by specifying the
VM category of the guest VM (category-based inclusion), and if you
protect the guest VM from the
VMs
page in this
policy (individual inclusion), the individual inclusion supersedes the
category-based inclusion. Effectively, only the protection policy that
protected the individual guest VM protects the guest VM.
For example, the guest VM
VM_SherlockH
is in the category
Department:Admin
, and you add this category to the
protection policy named
PP_AdminVMs
. Now, if you add
VM_SherlockH
from the
VMs
page
to another protection policy named
PP_VMs_UK
,
VM_SherlockH
is protected in
PP_VMs_UK
and
unprotected from
PP_AdminVMs
.
If you want to protect the guest VMs category wise, check the VM
categories that you want to protect from the list and click
Add
.
Figure.
Protection Policy Configuration: Add VM Categories
Click to enlarge
Prism Central includes built-in VM categories for frequently
encountered applications (for example, MS Exchange and Oracle). If the
VM category or value you want is not available, first create the
category with the required values, or update an existing category so
that it has the values you require. Doing so ensures that the VM
categories and values are available for selection. You can add VMs to
the category either before or after you configure the protection policy.
If the guest VMs have a common characteristic, such as belonging to a
specific application or location, create a VM category and add the guest
VMs into the category.
If you do not want to protect the guest VMs
category wise, proceed to the next step without checking VM
categories. You can add the guest VMs individually to the protection
policy later from the
VMs
page (see Adding Guest VMs Individually to a Protection Policy).
Click
Create
.
The protection policy with an Asynchronous replication schedule
is created. To verify the protection policy, see the
Protection Policies
page. If you check VM
categories in step h, the protection policy starts generating recovery
points of the guest VMs in those VM categories. To see the generated
recovery points, click the hamburger icon at the top-left corner of the
window and go to
VM Recovery Points
. Click the
recovery points for its information. You can see the time estimated for
the very first replication (seeding) to the recovery AZs.
Figure.
Recovery Points Overview
Click to enlarge
Application-consistent Recovery Point Conditions and Limitations
This topic describes the conditions and limitations for application-consistent recovery
points that you can generate through a protection policy. For information about the
operating systems that support the AOS version you have deployed, see the Compatibility Matrix.
Before taking an application-consistent recovery point, consider the workload type of
your guest VM.
Applications running in your guest VM must be able to quiesce I/O
operations. For example, For example, you can quiesce I/O operations for database
applications and similar workload types.
Before taking an application-consistent recovery point, install and enable Nutanix Guest
Tools (NGT) on your guest VM.
For installing and enabling NGT, see Nutanix Guest Tools in the
Prism Web
Console Guide
.
For guest VMs running on ESXi, consider these
points.
Install and enable NGT on guest VMs running on ESXi also. Application-consistent
recovery points fail for EFI boot-enabled Windows 2019 VMs running on ESXi without
installing NGT.
(vSphere) If you do not enable NGT and then try to take an application-consistent
recovery point, the system creates a Nutanix native recovery point with a single vSphere
host-based recovery point. The system deletes the vSphere host-based recovery point. If
you enable NGT and then try to take application-consistent recovery point, the system
directly captures a Nutanix native recovery point.
Do not delete the
.snapshot
folder in the vCenter.
The following table lists the operating systems that support application-consistent
recovery points with NGT installed.
Table 1.
Supported Operating Systems (NGT Installed)
Operating system
Version
Windows
Windows 2008 R2 through Windows 2019
Linux
CentOS 6.5 through 6.9 and 7.0 through 7.3
Red Hat Enterprise Linux (RHEL) 6.5 through 6.9 and 7.0 through 7.3.
Oracle Linux 6.5 and 7.0
SUSE Linux Enterprise Server (SLES) 11 SP1 through 11 SP4 and 12 SP1 through
12 SP3
Ubuntu 14.04
Application-consistent Recovery Points with Microsoft Volume Shadow Copy Service
(VSS)
To take application-consistent recovery points on Windows guest VMs, enable Microsoft
VSS services.
When you configure a protection policy and select
Take
App-Consistent Recovery Point
, the Nutanix cluster transparently invokes
the VSS (also known as Shadow copy or volume snapshot service).
Note:
This option is
available for ESXi and AHV only. However, you can use third-party backup products to
invoke VSS for Hyper-V.
To take application-consistent recovery points on guest VMs that use VSS, systems invoke
Nutanix native in-guest VmQuiesced Snapshot Service (VSS) agent. VSS framework takes
application-consistent recovery points without causing VM stuns (temporary unresponsive
VMs).
VSS framework enables third-party backup providers like Commvault and Rubrik to take
application-consistent snapshots on Nutanix platform in a hypervisor-agnostic manner.
The default and only backup type for VSS snapshots is
VSS_BT_COPY
(copy backup).
Third party Backup products can choose between VSS_BT_FULL (full backup
)and VSS_BT_COPY (copy backup) backup types.
Guest VMs with delta, SATA, and IDE disks do not support Nutanix VSS recovery
points.
Guest VMs with iSCSI attachments (LUNs) do not support Nutanix VSS recovery points.
Nutanix VSS recovery points fail for such guest VMs.
Do not take Nutanix enabled application-consistent recovery points while using any
third-party backup provider enabled VSS snapshots (for example, Veeam).
Pre-freeze and Post-thaw scripts
You can take application-consistent recovery points on NGT and Volume Shadow Copy
Service (VSS) enabled guest VMs. However, some applications require more steps before or
after the VSS operations to fully quiesce the guest VMs to an appropriate restore point or
state in which the system can capture a recovery point. Such applications need pre-freeze
and post-thaw scripts to run the necessary extra steps.
Any operation that the system must perform on a guest VM before replication or a
recovery point capture is a pre-freeze operation. For example, if a guest VM hosts a
database, you can enable hot backup of the database before replication using a pre-freeze
script. Similarly, any operation that the system must perform on guest VM after
replication or a recovery point capture is a post-thaw operation.
Tip:
Vendors
such as
CommVault
provide pre-freeze and post-thaw scripts. You can also
write your own pre-freeze and post-thaw scripts.
Script Requirements
For Windows VMs, you must administrator and have read, write, and execute
permissions on the scripts.
For Linux VMs, you must have root ownership and root access with 700 permissions
on the scripts.
For completion of any operation before or after replication or recovery point
capture, you must have both the pre_freeze and post_thaw scripts for the operation.
Timeout for both the scripts is 60 seconds.
A script must return 0 to indicate a successful run. A non-zero return value
implies that the script execution failed. The necessary log entries are available in
the NGT logs.
Tip:
(AHV) For a non-zero return value from the pre-freeze
script, the system captures a non application-consistent snapshot and raises an
alert on the Prism web console. Similarly, for a non-zero return value from the
post-thaw script, the system attempts to capture an application-consistent
snapshot once again. If the attempt fails, the system captures a non
application-consistent snapshot, and raises an alert on the Prism web
console.
Irrespective of whether the pre-freeze script execution is successful, the
corresponding post-thaw script runs.
Script Location
You can define Python or shell scripts or any executable or batch files at the
following locations in Linux or Windows VMs. The scripts can contain commands and
routines necessary to run specific operations on one or more applications.
In Windows VMs,
Batch script file path for pre_freeze scripts:
C:\Program Files\Nutanix\Scripts\pre_freeze.bat
Batch script file path for post_thaw scripts:
C:\Program Files\Nutanix\Scripts\post_thaw.bat
In Linux VMs,
Shell script file path for production
failover:
/usr/local/sbin/pre_freeze
Replace
pre_freeze
with the script name (without
extension).
Shell script file path for test failover:
/usr/local/sbin/post_thaw
Replace
post_thaw
with the script name (without
extension).
Note:
The scripts must have root ownership and root access with
700 permissions.
Script Sample
Note:
The following are only sample scripts and therefore must be modified to fit your
deployment.
For Linux VMs
#!/bin/sh
#pre_freeze-script
date >> '/scripts/pre_root.log'
echo -e "\n attempting to run pre_freeze script for MySQL as root user\n" >> /scripts/pre_root.log
if [ "$(id -u)" -eq "0" ]; then
python '/scripts/quiesce.py' &
echo -e "\n executing query flush tables with read lock to quiesce the database\n" >> /scripts/pre_freeze.log
echo -e "\n Database is in quiesce mode now\n" >> /scripts/pre_freeze.log
else
date >> '/scripts/pre_root.log'
echo -e "not root useri\n" >> '/scripts/pre_root.log'
fi
#!/bin/sh
#post_thaw-script
date >> '/scripts/post_root.log'
echo -e "\n attempting to run post_thaw script for MySQL as root user\n" >> /scripts/post_root.log
if [ "$(id -u)" -eq "0" ]; then
python '/scripts/unquiesce.py'
else
date >> '/scripts/post_root.log'
echo -e "not root useri\n" >> '/scripts/post_root.log'
fi
For Windows VMs
@echo off
echo Running pre_freeze script >C:\Progra~1\Nutanix\script\pre_freeze_log.txt
@echo off
echo Running post_thaw script >C:\Progra~1\Nutanix\script\post_thaw_log.txt
Note:
If any of these scripts prints excessive output to the console session, the
script freezes. To avoid script freeze, perform the following.
Add
@echo off
to your scripts.
Redirect the script output to a log file.
If you receive a non-zero return code from the pre-freeze script, the system
captures a non application-consistent recovery point and raises an alert on the Prism
web console. If you receive a non-zero return code from the post-thaw script, the system
attempts to capture an application-consistent snapshot once again. If that attempt
fails, the system captures a non application-consistent snapshot, and raises an alert on
the Prism web console.
Applications supporting application-consistent recovery points without scripts
Only the following applications support application-consistent recovery points without
pre-freeze and post-thaw scripts.
Microsoft SQL Server 2008, 2012, 2016, and 2019
Microsoft Exchange 2010
Microsoft Exchange 2013
Microsoft Exchange 2016
Nutanix does not support application-consistent recovery points on Windows VMs that have
mounted VHDX disks.
The system captures hypervisor-based recovery points only when you have VMware Tools
running on the guest VM and the guest VM does not have any independent disks attached to
it.
If these requirements are not met, the system captures crash-consistent
snapshots.
The following table provides detailed information on whether a recovery point is
application-consistent or not depending on the operating systems and hypervisors running
in your environment.
Note:
Installed and active means that the guest VM has the following.
NGT installed.
VSS capability enabled.
Powered on.
Actively communicating with the CVM.
Table 2.
Application-consistent Recovery Points
Server
ESXi
AHV
NGT status
Result
NGT status
Result
Microsoft Windows Server edition
Installed and active. Also pre-freeze and post-thaw scripts are
present.
Nutanix script-based VSS snapshots
Installed and active. Also pre-freeze and post-thaw scripts are
present.
Nutanix script-based VSS snapshots
Installed and active
Nutanix VSS-enabled snapshots.
Installed and active
Nutanix VSS-enabled snapshots
Not enabled
Hypervisor-based application-consistent or crash-consistent snapshots.
Not enabled
Crash-consistent snapshots
Microsoft Windows Client edition
Installed and active. Also pre-freeze and post-thaw scripts are
present.
Nutanix script-based VSS snapshots
Installed and active. Also pre-freeze and post-thaw scripts are
present.
Nutanix script-based VSS snapshots
Not enabled
Hypervisor-based snapshots or crash-consistent snapshots.
Not enabled
Crash-consistent snapshots
Linux VMs
Installed and active. Also pre-freeze and post-thaw scripts are
present.
Nutanix script-based VSS snapshots
Installed and active. Also pre-freeze and post-thaw scripts are
present.
Nutanix script-based VSS snapshots
Not enabled
Hypervisor-based snapshots or crash-consistent snapshots.
Not enabled
Crash-consistent snapshots
Creating a Recovery Plan (Nutanix Disaster Recovery)
To orchestrate the failover (disaster recovery) of the protected guest VMs to the
recovery AZ, create a recovery plan. After a failover, a recovery plan recovers the
protected guest VMs to the recovery AZ. If you have configured two on-prem recovery AZs
in a protection policy, create two recovery plans for DR—one for recovery to each recovery
AZ. The recovery plan synchronizes continuously to the recovery AZ in a bidirectional
way.
About this task
To create a recovery plan, do the following at the primary AZ. You can also create
a recovery plan at a recovery AZ. The recovery plan you create or update at a
recovery AZ synchronizes back to the primary AZ.
Procedure
Log on to the Prism Central web console.
Click the hamburger icon at the top-left corner of the window. Go to
Policies
>
Recovery Plans
in the left pane.
Figure.
Recovery Plan Configuration: Recovery Plans
Click to enlarge
Click
Create Recovery Plan
.
Specify the following information in the
Create Recovery
Plan
window.
Figure.
Recovery Plan Configuration: General
Click to enlarge
In the
General
tab, enter
Recovery Plan
Name
,
Recovery Plan Description
,
Primary Location
,
Recovery
Location
, and click
Next
.
From
Primary Location
and
Recovery
Location
drop-down lists, you can select either the local
AZ (AZ) or a non-local AZ to serve as your primary and
recovery AZs respectively.
Local AZ
represents the local
AZ (Prism Central). If you are configuring recovery plan to recover the
protected guest VMs to another Nutanix cluster at the same AZ, select
Local AZ
from both
Primary
Location
and
Recovery Location
drop-down
lists.
In the
Power On Sequence
tab, click
+ Add
Entities
to add the guest VMs to the start sequence.
Figure.
Recovery Plan Configuration: Add Entities
Click to enlarge
In the
Search Entities by
, select
VM
Name
from the drop-down list to specify guest VMs by
name.
In the
Search Entities by
, select
Category
from the drop-down list to specify
guest VMs by category.
To add the guest VMs or VM categories to the stage, select the VMs or
VM categories from the list.
Note:
The VMs listed in the search result are in the active state of
replication.
Click
Add
.
The selected guest VMs are added to the start sequence in a
single stage by default. You can also create multiple stages to add
guest VMs and define the order of their power-on sequence. For more
information about stages, see Stage Management.
Caution:
Do not include the guest VMs protected
with Asynchronous, NearSync, and Synchronous replication schedules in the
same recovery plan. You can include guest VMs protected with Asynchronous or
NearSync replication schedules in the same recovery plan. However, if you
combine these guest VMs with the guest VMs protected by Synchronous
replication schedules in a recovery plan, the recovery fails.
To automate in-guest script execution on the guest VMs during recovery,
select the individual guest VMs or VM categories in the stage and click
Manage Scripts
.
Note:
In-guest scripts allow you to automate various task executions
upon recovery of the guest VMs. For example, in-guest scripts can
help automate the tasks in the following scenarios.
After recovery, the guest VMs must use new DNS IP addresses
and also connect to a new database server that is already
running at the recovery AZ.
Traditionally, to achieve
this new configuration, you would manually log on to the
recovered VM and modify the relevant files. With
in-guest scripts, you have to write a script to automate
the required steps and enable the script when you
configure a recovery plan. The recovery plan execution
automatically invokes the script and performs the
reassigning of DNS IP address and reconnection to the
database server at the recovery AZ.
If guest VMs are part of domain controller
AZA.com
at the primary AZ
AZ1
, and after the guest VMs recover at the
AZ
AZ2
, you want to add the recovered guest
VMs to the domain controller
AZB.com
.
Traditionally, to reconfigure, you would manually log
on to the VM, remove the VM from an existing domain
controller, and then add the VM to a new domain
controller. With in-guest scripts, you can automate the
task of changing the domain controller.
Note:
In-guest script execution requires NGT version 1.9 or newer
installed on the VM. The in-guest scripts run as a part of the
recovery plan only if they have executable permissions for the following.
Administrator user (Windows)
Root user (Linux)
Note:
You can define a batch or shell script that executes automatically
in the guest VMs after their disaster recovery. Place two
scripts—one for production failover and the other for test
failover—at the following locations in the guest VMs with the
specified name.
Note:
When an in-guest script runs successfully, it returns code
0
. Any non-zero error code
signifies that the execution of the in-guest script was
unsuccessful.
Figure.
Recovery Plan Configuration: In-guest Script
Execution
Click to enlarge
To enable script execution, click
Enable
.
A command prompt
icon appears against the guest VMs or VM categories
to indicate that in-guest script execution is
enabled on those guest VMs or VM
categories.
To disable script execution, click
Disable
.
In the
Network Settings
tab, map networks in the primary
cluster to networks at the recovery cluster.
Figure.
Recovery Plan Configuration: Network Settings
Click to enlarge
Network mapping enables replicating the network configurations of the primary
Nutanix clusters to the recovery Nutanix clusters, and recover guest VMs into
the same subnet at the recovery Nutanix cluster. For example, if a guest VM is
in the
vlan0
subnet at the primary Nutanix cluster, you can
configure the network mapping to recover that guest VM in the same
vlan0
subnet at the recovery Nutanix cluster. To specify the
source (primary Nutanix cluster) and destination (recovery Nutanix cluster)
network information for network mapping, do the following in
Local AZ
(Primary)
and
PC 10.xx.xx.xxx (Recovery)
panes.
Under
Production
in
Virtual Network
or Port Group
drop-down list, select the production
subnet that contains the protected guest VMs. (optional) If the virtual
network is a non-IPAM network, specify the gateway IP address and prefix
length in the
Gateway IP/Prefix Length
field.
Under
Test Failback
in
Virtual
Network or Port Group
drop-down list, select the test
subnet that you want to use for testing failback from the recovery
Nutanix cluster. (optional) If the virtual network is a non-IPAM
network, specify the gateway IP address and prefix length in the
Gateway IP/Prefix Length
field.
To add more network mappings, click
Add Networks
at the top-right corner of the page, and then repeat the steps
6.a-6.b.
Note:
The primary and recovery Nutanix clusters
must have identical gateway IP addresses and prefix length. Therefore you
cannot use a test failover network for two or more network mappings in the
same recovery plan.
Click
Done
.
Note:
For ESXi, you can configure network mapping for both standard and
distributed (DVS) port groups. For more information about DVS, see VMware
documentation.
Caution:
Leap does not support VMware NSX-T datacenters. For more
information about NSX-T datacenters, see VMware documentation.
To perform VM-level static IP address mapping between the primary and the
recovery AZs, click
Advanced Settings
, click
Custom IP Mapping
, and then do the following.
Note:
The
Custom IP Mapping
shows all the guest VMs with
static IP address configured, NGT installed, and VNIC in the source subnet
specified in the network mapping.
To locate the guest VM, type the name of the guest VM in the filter
field.
A guest VM that has multiple NICs lists in multiple rows, allowing you
to specify an IP address mapping for each VNIC. All the fields
auto-populate with the IP addresses generated based on the offset IP
address-mapping scheme.
In the
Test Failback
field for the local AZ,
Production
field for the remote (recovery)
AZ, and
Test Failover
for the remote AZ, edit
the IP addresses.
Perform this step for all the IP addresses that you want to map.
Caution:
Do not edit the IP address assigned to the VNIC in
the local AZ. If you do not want to map static IP addresses for a
particular VNIC, you can proceed with the default
entries.
Click
Save
.
If you want to edit one or more VM-level static IP address mappings,
click
Edit
, and then change the IP address
mapping.
If VM-level static IP address mapping is configured between the primary and the
recovery Nutanix clusters and you want to use the default, offset-based IP
address-mapping scheme, click
Reset to Matching IP
Offset
.
Click
Done
.
The recovery plan is created. To verify the recovery plan, see the
Recovery Plans
page. You can modify the recovery plan
to change the recovery location, add, or remove the protected guest VMs. For
information about various operations that you can perform on a recovery plan,
see Recovery Plan Management.
Stage Management
A stage defines the order in which the protected guest VMs start at the recovery cluster. You
can create multiple stages to prioritize the start sequence of the guest VMs. In the
Power On Sequence
, the VMs in the preceding stage start before the
VMs in the succeeding stages. On recovery, it is desirable to start some VMs before the
others. For example, database VMs must start before the application VMs. Place all the
database VMs in the stage before the stage containing the application VMs, in the
Power On Sequence
.
Figure.
Recovery Plan Configuration: Power On Sequence
Click to enlarge
To Add a Stage in the Power-On Sequence and Add Guest VMs to It, Do the
Following.
Click
+Add New Stage
.
Click
+Add Entities
.
To add guest VMs to the current stage in the power-on sequence, do the following.
In the
Search Entities by
, select
VM
Name
from the drop-down list to specify guest VMs by name.
In the
Search Entities by
, select
Category
from the drop-down list to specify guest VMs by
category.
To add the guest VMs or VM categories to the stage, select the guest VMs or VM
categories from the list.
Note:
The VMs listed in the search result are in the active
state of replication.
Click
Add
.
To Remove a Stage from the Power-On Sequence, Do the Following.
Click
Actions
>
Remove Stage
Note:
You see
Actions
in a stage only when none of the
VMs in the stage are selected. When one or more VMs in the stage are selected, you see
More Actions
.
To Change the Position of a Stage in the Power-On Sequence, Do the Following.
To move a stage up or down in the power-on sequence, click
↑
or
↓
respectively, at the top-right corner of the stage.
To expand or collapse a stage, click
+
or
-
respectively, at the top-right corner of the stage.
To move VMs to a different stage, select the VMs, do the following.
Click
More Actions
>
Move
.
Select the target stage from the list.
Note:
You see
Move
in the
More Actions
only when you have defined two or more stages.
To Set a Delay Between the Power-On Sequence of Two Stages, Do the Following.
Click
+Add Delay
.
Enter the time in seconds.
Click
Add
.
To Add Guest VMs to an Existing Stage, Do the Following.
Click
Actions
>
Add Entities
.
Note:
You see
Actions
in a stage only when none of
the VMs in the stage are selected. When one or more VMs in the stage are
selected, you see
More Actions
.
To add VMs to the current stage in the power-on sequence, do the following.
In the
Search Entities by
, select
VM
Name
from the drop-down list to specify guest VMs by name.
In the
Search Entities by
, select
Category
from the drop-down list to specify guest VMs by
category.
To add the guest VMs or VM categories to the stage, select the guest VMs or VM
categories from the list.
Note:
The VMs listed in the search result are in the active
state of replication.
Click
Add
.
To Remove Guest VMs from an Existing Stage, Do the Following.
Select the VMs from the stage.
Click
More Actions
>
Remove
.
Note:
You see
More Actions
in a stage only when one
or more VMs in the stage are selected. When none of the VMs in the stage are
selected, you see
Actions
.
To Move Guest VMs to a Different Stage, Do the Following.
Select the VMs from the stage.
Click
More Actions
>
Move
.
Note:
You see
More Actions
in a stage only when one
or more VMs in the stage are selected. When none of the VMs in the stage are
selected, you see
Actions
.
You perform failover of the protected guest VMs when unplanned failure events (for example,
natural disasters) or planned events (for example, scheduled maintenance) happen at the
primary AZ (AZ) or the primary cluster. The protected guest VMs migrate to
the recovery AZ where you perform the failover operations. On recovery, the protected guest
VMs start in the Nutanix cluster you specify in the recovery plan that orchestrates the
failover.
The following are the types of failover operations.
Test failover
To ensure that the protected guest VMs failover efficiently to the recovery AZ, you
perform a test failover. When you perform a test failover, the guest VMs recover in the
virtual network designated for testing purposes at the recovery AZ. However, the guest
VMs at the primary AZ are not affected. Test failovers rely on the presence of VM
recovery points at the recovery AZs.
Planned failover
To ensure VM availability when you foresee service disruption at the primary AZ, you
perform a planned failover to the recovery AZ. For a planned failover to succeed, the
guest VMs must be available at the primary AZ. When you perform a planned failover, the
recovery plan first creates a recovery point of the protected guest VM, replicates the
recovery point to the recovery AZ, and then starts the guest VM at the recovery AZ.
The recovery point used for migration is retained indefinitely. After a planned failover,
the guest VMs no longer run at the primary AZ.
Unplanned failover
To ensure VM availability when a disaster causing service disruption occurs at the
primary AZ, you perform an unplanned failover to the recovery AZ. In an unplanned
failover, you can expect some data loss to occur. The maximum data loss possible is equal
to the least RPO you specify in the protection policy, or the data that was generated
after the last manual recovery point for a given guest VM. In an unplanned failover, by
default, the protected guest VMs recover from the most recent recovery point. However, you
can recover from an earlier recovery point by selecting a date and time of the recovery
point.
At the recovery AZ, the guest VMs can recover using the recovery points
replicated from the primary AZ only. The guest VMs cannot recover using the local
recovery points. For example, if you perform an unplanned failover from the primary AZ
AZ1
to the recovery AZ
AZ2
, the guest VMs recover at
AZ2
using the recovery points replicated from
AZ1
to
AZ2
.
You can perform a planned or an unplanned failover in different scenarios of network failure.
For more information about network failure scenarios, see Nutanix Disaster Recovery and Xi Leap Failover Scenarios.
At the recovery AZ after a failover, the recovery plan creates only the VM category that
was used to include the guest VM in the recovery plan. Manually create the remaining VM
categories at the recovery AZ and associate the guest VMs with those categories.
The recovered guest VMs generate recovery points as per the replication schedule that
protects it even after recovery. The recovery points replicate back to the primary AZ when
the primary AZ starts functioning. The approach for reverse replication enables you to
perform failover of the guest VMs from the recovery AZ back to the primary AZ (failback).
The same recovery plan applies to both the failover and the failback operations. Only, for
failover, you must perform the failover operations on the recovery plan at the recovery AZ
while for failback, you must perform the failover operations on the recovery plan at the
primary AZ. For example, if a guest VM fails over from
AZ1 (Local)
to
AZ2
, the failback fails over the same VMs from
AZ2 (Local)
back to
AZ1
.
Nutanix Disaster Recovery and Xi Leap Failover Scenarios
You have the flexibility to perform a real or simulated failover for the full and partial
workloads (with or without networking). The term virtual network is used differently on
on-prem clusters and Xi Cloud Services. In Xi Cloud Services, the term virtual network is used
to describe the two built-in virtual networks—production and test. Virtual networks on the
on-prem clusters are virtual subnets bound to a single VLAN. Manually create these virtual
subnets, and create separate virtual subnets for production and test purposes. Create these
virtual subnets before you configure recovery plans. When configuring a recovery plan, you map
the virtual subnets at the primary AZ to the virtual subnets at the recovery AZ.
Figure.
Failover in Network Mapping
Click to enlarge
The following are the various scenarios that you can encounter in Leap configurations for
disaster recovery (DR) to an on-prem AZ (AZ) or to Xi Cloud (Xi Leap). Each
scenario is explained with the required network-mapping configuration for Xi Leap. However,
the configuration remains the same irrespective of disaster recovery (DR) using Leap or Xi
Leap. You can either create a recovery plan with the following network mappings (see Creating a Recovery Plan (Nutanix Disaster Recovery)) or update an existing recovery plan with the
following network mappings (see Updating a Recovery Plan).
Scenario 1: Leap Failover (Full Network Failover)
Full network failure is the most common scenario. In this case, it is desirable to bring up
the whole primary AZ in the Xi Cloud. All the subnets must failover, and the WAN IP
address must change from the on-prem IP address to the Xi WAN IP address. Floating IP
addresses can be assigned to individual guest VMs, otherwise, everything use Xi network
address translation (NAT) for external communication.
Perform the failover when the on-prem subnets are down and jump the host available on the
public Internet through the floating IP address of Xi production network.
Figure.
Full Network Failover
Click to enlarge
To set up the recovery plan that orchestrates the full network failover, perform the
following.
Open the
Network Settings
page to configure network mappings in a
recovery plan.
Select the
Local AZ
>
Production
>
Virtual Network or Port Group
.
The selection auto-populates the Xi production and test failover
subnets.
Select the
Outbound Internet Access
switch to allow the Xi NAT to
use for Internet access.
Dynamically assign the floating IP addresses to the guest VMs you select in the recovery
plan.
Perform steps 1–4 for every subnet.
Figure.
Recovery Plan Configuration: Network Settings
Click to enlarge
Scenario 2: Xi Network Failover (Partial Network Failover)
You want to failover one or more subnets from the primary AZ to Xi Cloud. The
communications between the AZs happen through the VPN or using the external NAT or
floating IP addresses. A use case of this type of scenario is that the primary AZ needs
maintenance, but some of its subnets must see no downtime.
Perform partial failover when some subnets are active in the production networks at both
on-prem and Xi Cloud, and jump the host available on the public Internet through the
floating IP address of Xi production network.
On-prem guest VMs can connect to the guest VMs on the Xi Cloud Services.
Figure.
Partial Network Failover
Click to enlarge
To set up the recovery plan that orchestrates the partial network failover, perform the
following.
Open the
Network Settings
page to configure network mappings in a
recovery plan.
Select the
Local AZ
>
Production
>
Virtual Network or Port Group
.
The selection auto-populates the Xi production and test failover
subnets.
Select the
Outbound Internet Access
switch to allow the Xi NAT to
use for Internet access.
Dynamically assign the floating IP addresses to the guest VMs you select in the recovery
plan.
Perform steps 1–4 for one or more subnets based on the maintenance
plan.
Figure.
Recovery Plan Configuration: Network Settings
Click to enlarge
Scenario 3: Xi Network Failover (Partial Subnet Network Failover)
You want to failover some guest VMs to Xi Cloud, while keeping the other guest VMs up and
running at the on-prem cluster (primary AZ). A use case of this type of scenario is that
the primary AZ needs maintenance, but some of its guest VMs must see no downtime.
This scenario requires changing IP addresses for the guest VMs running at Xi Cloud. Since
you cannot have the subnet active on both the AZs, create a subnet to host the failed over
guest VMs. Jump the host available on the public Internet through the floating IP address of
Xi production network.
On-prem guest VMs can connect to the guest VMs on the Xi Cloud Services.
Figure.
Partial Subnet Network Failover
Click to enlarge
To set up the recovery plan that orchestrates the partial subnet network failover, perform
the following.
Open the
Network Settings
page to configure network mappings in a
recovery plan.
Select the
Local AZ
>
Production
>
Virtual Network or Port Group
.
The selection auto-populates the Xi production and test failover
subnets for a full subnet failover
Note:
In this case, you have created subnets on
the Xi Cloud Services also. Choose that subnets to avoid full subnet failover (scenario
1).
Select the
Outbound Internet Access
switch to allow the Xi NAT to
use for Internet access.
Dynamically assign the floating IP addresses to the guest VMs you select in the recovery
plan.
Perform steps 1–4 for one or more subnets based on the maintenance
plan.
Figure.
Recovery Plan Configuration: Network Settings
Click to enlarge
Scenario 4: Xi Network Failover (Test Failover and Failback)
You want to test all the preceding three scenarios by creating an isolated test network so
that no routing or IP address conflict happens. Clone all the guest VMs from a local
recovery point and bring up to test failover operations. Test failover test when all on-prem
subnets are active and on-prem guest VMs can connect to the guest VMs at the Xi Cloud. Jump
the host available on the public Internet through the floating IP address of Xi production
network.
Figure.
Test Failover & Failback
Click to enlarge
In this case, focus on the test failover section when creating the recovery plan. When you
select a local AZ production subnet, it copies to the test network. You can go one step
further and create a test subnet at the Xi Cloud.
Figure.
Recovery Plan Configuration: Network Settings
Click to enlarge
After the guest VMs test failover to Xi Cloud, you can do a test failback to the primary
AZ.
Note:
Make a test subnet in advance for the failback to the on-prem
cluster.
Figure.
Recovery Plan Configuration: Network Settings
Click to enlarge
Failover and Failback Operations (Nutanix Disaster Recovery)
You can perform test failover, planned failover, and unplanned failover of the guest VMs
protected with Asynchronous replication schedule across different Nutanix clusters at the same
or different on-prem AZs (AZs). The steps to perform test, planned, and
unplanned failover are largely the same irrespective of the replication schedules that protect
the guest VMs.
Performing a Test Failover (Leap)
After you create a recovery plan, you can run a test failover periodically to ensure
that the failover occurs smoothly when required. To perform a test failover, do the
following procedure at the recovery AZ. If you have two recovery AZs for DR, perform the
test at the AZ where you want to recover the guest VMs.
Procedure
Log on to the Prism Central web console.
Click the hamburger icon at the top-left corner of the window. Go to
Policies
>
Recovery Plans
in the left pane.
Select the recovery plan that you want to test.
Click
Test
from the
Actions
drop-down menu.
Figure.
Test Failover (Drop-down)
Click to enlarge
Test Recovery Plan
window shows. The window
auto-populates the
Failover From
and
Failover
To
locations from the recovery plan you select in step 3.
Failover To
location is
Local AZ
by default and is unavailable for editing.
Figure.
Test Recovery Plan
Click to enlarge
Click
+ Add target clusters
if you want to failover to
specific Nutanix clusters at the recovery AZ.
If you do not add target clusters, the recovery plan recovers the guest VMs to
any eligible cluster at the recovery AZ.
Click
Test
.
The
Test Recovery Plan
dialog box lists the
errors and warnings, if any, and allows you to stop or continue the test
operation. If there are no errors or you resolve the errors in step 7, the guest
VMs failover to the recovery cluster.
If you see errors, do the following.
To review errors or warnings, click
View Details
in the description.
Resolve the error conditions and then restart the
test procedure.
Select one of the following.
To stop the failover operation, click
Abort
.
To continue the failover operation despite the warnings, click
Execute Anyway
.
Note:
You cannot
continue the failover operation when the validation fails
with errors.
Cleaning up Test VMs (Leap)
After testing a recovery plan, you can remove the test VMs that the recovery plan
creates in the recovery test network. To clean up the test VMs, do the following at the
recovery AZ where the test failover created the test VMs.
Procedure
Log on to the Prism Central web console.
Click the hamburger icon at the top-left corner of the window. Go to
Policies
>
Recovery Plans
in the left pane.
Select the recovery plans whose test VMs you want to remove.
Click
Clean Up Test VMs
from the
Actions
drop-down menu.
Clean Up Test VMs
dialog box shows with the name of the
recovery plan you selected in step 3.
Click
Clean
.
Figure.
Clean Up Test VMs
Click to enlarge
Performing a Planned Failover (Leap)
If there is a planned event (for example, scheduled maintenance of guest VMs) at the
primary AZ (AZ), perform a planned failover to the recovery AZ. To
perform a planned failover, do the following procedure at the recovery AZ. If you have two
recovery AZs for DR, perform the failover at the AZ where you want to recover the guest
VMs.
Procedure
Log on to the Prism Central web console.
Click the hamburger icon at the top-left corner of the window. Go to
Policies
>
Recovery Plans
in the left pane.
Select a recovery plan for the failover operation.
Click
Failover
from the
Actions
drop-down menu.
Note:
If you select more than one recovery plan in step 3, the
Failover
action is available only when the
selected recovery plans have the same primary and recovery locations.
Specify the following information in the
Failover from Recovery
Plan
window. The window auto-populates the
Failover
From
and
Failover To
locations from the
recovery plan you select in step 3.
Figure.
Planned Failover
Click to enlarge
Failover Type
: Click
Planned
Failover
.
Warning:
Do not check
Live Migrate
VMs
. Live migration works only for the planned
failover of the guest VMs protected in Synchronous replication
schedule. If you check
Live Migrate VMs
for
the planned failover of the guest VMs protected in Asynchronous or
NearSync replication schedule, the failover task fails.
Click
+ Add target clusters
if you want to
failover to specific Nutanix clusters at the recovery AZ.
Figure.
Planned Failover: Select Recovery Cluster
Click to enlarge
If you do not add target clusters, the recovery plan recovers the
guest VMs to any eligible cluster at the recovery AZ.
Click
Failover
.
The
Failover from Recovery Plan
dialog box lists
the errors and warnings, if any, and allows you to stop or continue the failover
operation. If there are no errors or you resolve the errors in step 6, the guest
VMs failover to the recovery Nutanix cluster.
If you see errors, do the following.
To review errors or warnings, click
View Details
in the description.
Resolve the error conditions and then restart the
failover procedure.
Select one of the following.
To stop the failover operation, click
Abort
.
To continue the failover operation despite the warnings, click
Execute Anyway
.
Note:
You cannot
continue the failover operation when the validation fails
with errors.
Note:
The entities of AHV/ESXi clusters recover at a different path on the ESXi
clusters if their files conflict with the existing files on the recovery
ESXi cluster. For example, there is a file name conflict if a VM (VM1)
migrates to a recovery cluster that already has a VM (VM1) in the same
container.
However, the entities recover at a different path with
VmRecoveredAtAlternatePath
alert only
if the following conditions are met.
Prism Element running on both the primary and the recovery Nutanix
clusters are of version 5.17 or newer.
A path for the entity recovery is not defined while initiating the
failover operation.
The protected entities do not have shared disk/s.
If these conditions are not satisfied, the failover operation fails.
Performing an Unplanned Failover (Leap)
If there is an unplanned event (for example, a natural disaster or network failure)
at the primary AZ (AZ), perform an unplanned failover to the recovery AZ.
To perform an unplanned failover, do the following procedure at the recovery AZ. If you
have two recovery AZs for DR, perform the failover at the AZ where you want to recover
the guest VMs.
Procedure
Log on to the Prism Central web console.
Click the hamburger icon at the top-left corner of the window. Go to
Policies
>
Recovery Plans
in the left pane.
Select a recovery plan for the failover operation.
Click
Failover
from the
Actions
drop-down menu.
Note:
If you select more than one recovery plan in step 3, the
Failover
action is available only when the
selected recovery plans have the same primary and recovery locations.
Specify the following information in the
Failover from Recovery
Plan
window. The window auto-populates the
Failover
From
and
Failover To
locations from the
recovery plan you select in step 3.
Figure.
Unplanned Failover
Click to enlarge
Failover Type
: Click
Unplanned
Failover
and do one of the following.
Click
Recover from latest Recovery Point
to use the latest recovery point for recovery.
Click
Recover from specific point in time
to use a recovery point taken at a specific point in time for
recovery.
Note:
If you click
Recover from
specific point in time
, select a Nutanix cluster
that hosts the specific point in time recovery point (step 4.b).
If you do not select a cluster, or select multiple clusters
where the same recovery points exist, the guest VMs fail to
recover efficiently because the system encounters more than one
recovery point at the recovery AZ. For example, if a primary
AZ
AZ1
replicates the same recovery points to two
clusters
CLA
and
CLB
at AZ
AZ2
, select either the cluster
CLA
or the cluster
CLB
as the target cluster when you
click to recover from a specific point in time. If you select
both
CLA
and
CLB
, the guest VMs fail
to recover.
Click
+ Add target clusters
if you want to
failover to specific Nutanix clusters at the recovery AZ.
Figure.
Unplanned Failover: Select Recovery Cluster
Click to enlarge
If you do not add target clusters, the recovery plan recovers the
guest VMs to any eligible cluster at the recovery AZ.
Note:
If recovery plans contain VM categories, the
VMs from those categories recover in the same category after an
unplanned failover to the recovery AZ. Also, the recovery points keep
generating at the recovery AZ for those recovered VMs. Since the VM
count represents the number of recoverable VMs (calculated from recovery
points), the recovered VMs and their newly created recovery points sum
up. Their sum gives double the count of the originally recovered VMs on
the recovery plans page. Now, if some VMs belonging to the given
category at the primary or recovery AZ are deleted, the VM count at
both AZs still stay the same until the recovery points of deleted VMs
expire. For example, when two VMs have failed over, the recovery plans
page at the recovery AZ shows four VMs (two replicated recovery points
from source and two newly generated recovery points). The page shows
four VMs even if the VMs are deleted from the primary or recovery AZ.
The VM count synchronizes and becomes consistent in the subsequent RPO
cycle conforming to the retention policy set in the protection policy
(due to the expiration of recovery points).
Click
Failover
.
The
Failover from Recovery Plan
dialog box lists
the errors and warnings, if any, and allows you to stop or continue the failover
operation. If there are no errors or you resolve the errors in step 6, the guest
VMs failover to the recovery Nutanix cluster.
If you see errors, do the following.
To review errors or warnings, click
View Details
in the description.
Resolve the error conditions and then restart the
failover procedure.
Select one of the following.
To stop the failover operation, click
Abort
.
To continue the failover operation despite the warnings, click
Execute Anyway
.
Note:
You cannot
continue the failover operation when the validation fails
with errors.
Note:
To avoid conflicts when the primary
AZ becomes active after the failover, shut down the guest VMs
associated with this recovery plan. Manually power off the guest VMs on
either primary or recovery AZ after the failover is complete. You can
also block the guest VMs associated with this recovery plan through the firewall.
Note:
The entities of AHV/ESXi clusters recover at a different path on the ESXi
clusters if their files conflict with the existing files on the recovery
ESXi cluster. For example, there is a file name conflict if a VM (VM1)
migrates to a recovery cluster that already has a VM (VM1) in the same
container.
However, the entities recover at a different path with
VmRecoveredAtAlternatePath
alert only
if the following conditions are met.
Prism Element running on both the primary and the recovery Nutanix
clusters are of version 5.17 or newer.
A path for the entity recovery is not defined while initiating the
failover operation.
The protected entities do not have shared disk/s.
If these conditions are not satisfied, the failover operation fails.
Performing Failback (Leap)
A failback is failover of the guest VMs from the recovery AZ (AZ)
back to the primary AZ. The same recovery plan applies to both the failover and the
failback operations. Only, for failover, you must perform the failover operations on the
recovery plan at the recovery AZ while for failback, you must perform the failover
operations on the recovery plan at the primary AZ.
About this task
To perform a failback, do the following procedure at the primary AZ.
Procedure
Log on to the Prism Central web console.
Click the hamburger icon at the top-left corner of the window. Go to
Policies
>
Recovery Plans
in the left pane.
Select a recovery plan for the failover operation.
Click
Failover
from the
Actions
drop-down menu.
Note:
If you select more than one recovery plan in step 3, the
Failover
action is available only when the
selected recovery plans have the same primary and recovery locations.
Specify the following information in the
Failover from Recovery
Plan
window. The window auto-populates the
Failover
From
and
Failover To
locations from the
recovery plan you select in step 3.
Figure.
Unplanned Failover
Click to enlarge
Failover Type
: Click
Unplanned
Failover
and do one of the following.
Tip:
You can also click
Planned
Failover
to perform planned failover procedure for a
failback.
Click
Recover from latest Recovery Point
to use the latest recovery point for recovery.
Click
Recover from specific point in time
to use a recovery point taken at a specific point in time for
recovery.
Click
+ Add target clusters
if you want to
failover to specific Nutanix clusters at the primary AZ.
If you do not add target clusters, the recovery plan recovers the
guest VMs to any eligible cluster at the primary AZ.
Note:
If recovery plans contain VM categories, the
VMs from those categories recover in the same category after an
unplanned failover to the recovery AZ. Also, the recovery points keep
generating at the recovery AZ for those recovered VMs. Since the VM
count represents the number of recoverable VMs (calculated from recovery
points), the recovered VMs and their newly created recovery points sum
up. Their sum gives double the count of the originally recovered VMs on
the recovery plans page. Now, if some VMs belonging to the given
category at the primary or recovery AZ are deleted, the VM count at
both AZs still stay the same until the recovery points of deleted VMs
expire. For example, when two VMs have failed over, the recovery plans
page at the recovery AZ shows four VMs (two replicated recovery points
from source and two newly generated recovery points). The page shows
four VMs even if the VMs are deleted from the primary or recovery AZ.
The VM count synchronizes and becomes consistent in the subsequent RPO
cycle conforming to the retention policy set in the protection policy
(due to the expiration of recovery points).
Click
Failover
.
The
Failover from Recovery Plan
dialog box lists
the errors and warnings, if any, and allows you to stop or continue the failover
operation. If there are no errors or you resolve the errors in step 6, the guest
VMs failover to the recovery cluster.
If you see errors, do the following.
To review errors or warnings, click
View Details
in the description.
Resolve the error conditions and then restart the
failover procedure.
Select one of the following.
To stop the failover operation, click
Abort
.
To continue the failover operation despite the warnings, click
Execute Anyway
.
Note:
You cannot
continue the failover operation when the validation fails
with errors.
Note:
To avoid conflicts when the primary
AZ becomes active after the failover, shut down the guest VMs
associated with this recovery plan. Manually power off the guest VMs on
either primary or recovery AZ after the failover is complete. You can
also block the guest VMs associated with this recovery plan through the firewall.
Note:
The entities of AHV/ESXi clusters recover at a different path on the ESXi
clusters if their files conflict with the existing files on the recovery
ESXi cluster. For example, there is a file name conflict if a VM (VM1)
migrates to a recovery cluster that already has a VM (VM1) in the same
container.
However, the entities recover at a different path with
VmRecoveredAtAlternatePath
alert only
if the following conditions are met.
Prism Element running on both the primary and the recovery Nutanix
clusters are of version 5.17 or newer.
A path for the entity recovery is not defined while initiating the
failover operation.
The protected entities do not have shared disk/s.
If these conditions are not satisfied, the failover operation fails.
Monitoring a Failover Operation (Leap)
After you trigger a failover operation, you can monitor failover-related tasks. To
monitor a failover, perform the following procedure at the recovery AZ. If you have two
recovery AZs for DR, perform the procedure at the AZ where you trigger the
failover.
Procedure
Log on to the Prism Central web console.
Click the hamburger icon at the top-left corner of the window. Go to
Policies
>
Recovery Plans
in the left pane.
Click the name of the recovery plan for which you triggered failover.
Click the
Tasks
tab.
The left pane displays the overall status. The table in the details pane
lists all the running tasks and their individual statuses.
Leap Role-Based Access Control (RBAC)
You can configure RBAC policies allowing other Prism Central Active Directory users
(non-administrator roles) to perform operations on recovery points and recovery plans. This
section guides you to configure recovery plan RBAC policies. For information about RBAC
policies for recovery points, see Controlling User Access (RBAC) in the
Nutanix
Security Guide
. Perform the following steps to configure recovery plan RBAC
policies.
Note:
You can configure recovery plan RBAC policies for Leap deployments with single IAM v2
enabled Prism Central version 2022.4 or newer only.
Create a custom role in Prism Central. See Creating a Custom Role.
You must create a custom role because none of the in-built roles support recovery
plan operations.
Tip:
To modify or delete a custom role, see Modifying a Custom Role. For more information about user role
management, see
Security and User Management
in the
Prism Central
Guide
.
Assign permissions to the custom role. See Custom Role Permissions.
Assign entities to the custom role. See Assigning a Role.
The custom role is created. The Active Directory (AD) users or User Groups can now
log on to Prism Central, view the assigned recovery plans, and perform recovery plan
operations. For recovery plan operations, see Failover and Failback Operations (Nutanix Disaster Recovery).
Note:
After an
entity failover, the Access Control Policies (ACP) where the access is based on
ownership, project, or category is retained on the recovery AZ. The access to an
entity is revoked in the following scenarios.
When you perform an unplanned failover of the entity.
The entity access is
revoked because the entity UUID changes after the unplanned failover.
When the entity access is cluster based.
Creating a Custom Role
About this task
To create a custom role, do the following:
Procedure
Go to the roles dashboard (select
Administration
>
Roles
in the pull-down menu) and click the
Create
Role
button.
The
Roles
page appears. See Custom Role Permissions for a list of the
permissions available for each custom role option.
In the
Roles
page, do the following in the indicated
fields:
Role Name
: Enter a name for the new role.
Description
(optional): Enter a description of
the role.
Note:
All entity types are listed by default, but you can display just a
subset by entering a string in the
Filter
Entities
search field.
Figure.
Filter Entities
Click to enlarge
Select an entity you want to add to this role and provide desired
access permissions from the available options. The access permissions
vary depending on the selected entity.
For example, for the
VM
entity, click the
radio button for the desired VM permissions:
No Access
View Access
Basic Access
Edit Access
Set Custom Permissions
If you select
Set Custom Permissions
, click
the
Change
link to display the
Custom VM Permissions
window, check all
the permissions you want to enable, and then click the
Save
button. Optionally, check the
Allow VM Creation
box to allow this role
to create VMs.
Figure.
Custom VM Permissions Window
Click to enlarge
Recovery Plan
: Click the radio button for the
desired permissions for recovery plan operations (
No
Access
,
View Access
,
Test Execution Access
,
Full
Execution Access
, or
Set Custom
Permissions
). If you specify custom permissions, click
the
Change
link to display the
Custom
Recovery Plan Permissions
window, check all the
permissions you want to enable (see Custom Role Permissions), and then click the
Save
button.
Figure.
Custom Recovery Plan Permissions Window
Click to enlarge
Blueprint
: Click the radio button for the
desired blueprint permissions (
No Access
,
View Access
,
Basic
Access
, or
Set Custom
Permissions
). Check the
Allow Blueprint
Creation
box to allow this role to create blueprints.
If you specify custom permissions, click the
Change
link to display the
Custom
Blueprint Permissions
window, check all the permissions
you want to enable, and then click the
Save
button.
Figure.
Custom Blueprint Permissions Window
Click to enlarge
Marketplace Item
: Click the radio button for the
desired marketplace permissions (
No Access
,
View marketplace and published blueprints
,
View marketplace and publish new blueprints
,
or
Set custom permissions
). If you specify
custom permissions, click the
Change
link to
display the
Custom Marketplace Item Permissions
window, check all the permissions you want to enable, and then click the
Save
button.
Note:
The permission you enable for a
Marketplace
Item
implicitly applies to a
Catalog
Item
entity. For example, if you select
No Access
permission for the
Marketplace Item
entity while creating
the custom role, the custom role will not have access to the
Catalog Item
entity as well.
Figure.
Custom Marketplace Permissions Window
Click to enlarge
Report
: Click the radio button for the desired
report permissions (
No Access
,
View
Only
,
Edit Access
, or
Set Custom Permissions
). If you specify
custom permissions, click the
Change
link to
display the
Custom Report Permissions
window,
check all the permissions you want to enable, and then click the
Save
button.
Figure.
Custom VM Permissions Window
Click to enlarge
Cluster
: Click the radio button for the desired
cluster permissions (
No Access
or
Cluster Access
).
Subnet
: Click the radio button for the desired
subnet permissions (
No Access
or
Subnet Access
).
Image
: Click the radio button for the desired
image permissions (
No Access
,
View
Only
, or
Set Custom Permissions
).
If you specify custom permissions, click the
Change
link to display the
Custom
Image Permissions
window, check all the permissions you
want to enable, and then click the
Save
button.
Figure.
Custom Image Permissions Window
Click to enlarge
OVA
: Click the radio button for the desired OVA
permissions (
No Access
,
View
Only
,
Full Access
or
Set Custom Permissions
). If you specify
custom permissions, click the
Change
link to
display the
Custom OVA Permissions
window, check
all the permissions you want to enable, and then click the
Save
button.
Figure.
Custom OVA Permissions Window
Click to enlarge
Object Store
: Click the radio button for the
desired object store permissions (
No Access
,
View Access
,
Full
Access
or
Set Custom
Permissions
). If you specify custom permissions, click the
Change
link to display the
Custom
Object Store Permissions
window, check the
Allow Object Store creation
to allow creation
of an object store, check all the permissions you want to enable, and
then click the
Save
button.
Figure.
Custom Object Store Permissions
Click to enlarge
Click
Save
to create the role. The page closes and the
new role appears in the
Roles
view list.
Modifying a Custom Role
About this task
Perform the following procedure to modify or delete a custom role.
Procedure
Go to the roles dashboard and select
(check the box for) the desired role from the list.
Do one of the following:
To modify the role, select
Update Role
from the
Actions
pull-down list. The
Roles
page for that role appears. Update the field
values as desired and then click
Save
. See Creating a Custom Role for field
descriptions.
To delete the role, select
Delete
from the
Action
pull-down list. A confirmation message is
displayed. Click
OK
to delete and remove the role
from the list.
Custom Role Permissions
A selection of permission options are available when creating a custom
role.
The following table lists the permissions you can grant when creating or modifying a custom
role. When you select an option for an entity, the permissions listed for that option are
granted. If you select
Set custom permissions
, a complete list of
available permissions for that entity appears. Select the desired permissions from that
list.
You can assign permissions for the
VM Recovery Point
entity to users or user groups in the following two ways.
Manually assign permission for each VM where the recovery point is
created.
Assign permission using Categories in the Role Assignment workflow.
Tip:
When a recovery point is created, it is associated with the
same category as the VM.
VM
No Access
(none)
View Access
Access Console VM, View VM
Basic Access
Access Console VM, Update VM Power State, View VM
Edit Access
Access Console VM, Update VM, View Subnet, View VM
Full Access
Access Console VM, Clone VM, Create VM, Delete VM, Export VM, Update VM, Update
VM Boot Config, Update VM CPU, Update VM Categories, Update VM Description, Update
VM Disk List, Update VM GPU List, Update VM Memory, Update VM NIC List, Update VM
Owner, Update VM Power State, Update VM Project, View Cluster, View Subnet, View
VM.
Set Custom Permissions (select from list)
Access Console VM, Clone VM, Create VM, Delete VM, Update VM, Update VM Boot
Config, Update VM CPU, Update VM Categories, Update VM Disk List, Update VM GPU
List, Update VM Memory, Update VM NIC List, Update VM Owner, Update VM Power State,
Update VM Project, View Cluster, View Subnet, View VM.
Granular permissions (applicable if IAM is enabled, see Granular Role-Based Access Control (RBAC))
for details.
Allow VM Power Off, Allow VM Power On, Allow VM Reboot, Allow VM Reset, Expand VM
Disk Size, Mount VM CDROM, Unmount VM CDROM, Update VM Memory Overcommit, Update
VM NGT Config, Update VM Power State Mechanism
Note:
The role has full access if you select
Allow File Server creation
.
The following table describe the permissions.
Note:
By default, assigning certain permissions to a user role might
implicitly assign more permissions to that role. However, the implicitly assigned
permissions will not be displayed in the details page for that role. These permissions are
displayed only if you manually assign them to that role.
Permission
Description
Assigned Implicilty By
Create App
Allows to create an application.
Delete App
Allows to delete an application.
View App
Allows to view an application.
Action Run App
Allows to run action on an application.
Download App Runlog
Allows to download an application runlog.
Abort App Runlog
Allows to abort an application runlog.
Access Console VM
Allows to access the console of a virtual machine.
Create VM
Allows to create a virtual machine.
View VM
Allows to view a virtual machine.
Clone VM
Allows to clone a virtual machine.
Delete VM
Allows to delete a virtual machine.
Export VM
Allows to export a virtual machine
Snapshot VM
Allows to snapshot a virtual machine.
View VM Recovery Point
Allows to view a vm_recovery_point.
Update VM Recovery Point
Allows to update a vm_recovery_point.
Delete VM Recovery Point
Allows to delete a vm_recovery_point.
Restore VM Recovery Point
Allows to restore a vm_recovery_point.
Update VM
Allows to update a virtual machine.
Update VM Boot Config
Allows to update a virtual machine's boot configuration.
Update VM
Update VM CPU
Allows to update a virtual machine's CPU configuration.
Update VM
Update VM Categories
Allows to update a virtual machine's categories.
Update VM
Update VM Description
Allows to update a virtual machine's description.
Update VM
Update VM GPU List
Allows to update a virtual machine's GPUs.
Update VM
Update VM NIC List
Allows to update a virtual machine's NICs.
Update VM
Update VM Owner
Allows to update a virtual machine's owner.
Update VM
Update VM Project
Allows to update a virtual machine's project.
Update VM
Update VM NGT Config
Allows updates to a virtual machine's Nutanix Guest Tools
configuration.
Update VM
Update VM Power State
Allows updates to a virtual machine's power state.
Update VM
Update VM Disk List
Allows to update a virtual machine's disks.
Update VM
Update VM Memory
Allows to update a virtual machine's memory configuration.
Update VM
Update VM Power State Mechanism
Allows updates to a virtual machine's power state mechanism.
Update VM or Update VM Power State
Allow VM Power Off
Allows power off and shutdown operations on a virtual
machine.
Update VM or Update VM Power State
Allow VM Power On
Allows power on operation on a virtual machine.
Update VM or Update VM Power State
Allow VM Reboot
Allows reboot operation on a virtual machine.
Update VM or Update VM Power State
Expand VM Disk Size
Allows to expand a virtual machine's disk size.
Update VM or Update VM Disk List
Mount VM CDROM
Allows to mount an ISO to virtual machine's CDROM.
Update VM or Update VM Disk List
Unmount VM CDROM
Allows to unmount ISO from virtual machine's CDROM.
Update VM or Update VM Disk List
Update VM Memory Overcommit
Allows to update a virtual machine's memory overcommit
configuration.
Update VM or Update VM Memory
Allow VM Reset
Allows reset (hard reboot) operation on a virtual machine.
Update VM, Update VM Power State, or Allow VM Reboot
View Cluster
Allows to view a cluster.
Update Cluster
Allows to update a cluster.
Create Image
Allows to create an image.
View Image
Allows to view a image.
Copy Image Remote
Allows to copy an image from local PC to remote PC.
Delete Image
Allows to delete an image.
Migrate Image
Allows to migrate an image from PE to PC.
Update Image
Allows to update a image.
Create Image Placement Policy
Allows to create an image placement policy.
View Image Placement Policy
Allows to view an image placement policy.
Delete Image Placement Policy
Allows to delete an image placement policy.
Update Image Placement Policy
Allows to update an image placement policy.
Create AWS VM
Allows to create an AWS virtual machine.
View AWS VM
Allows to view an AWS virtual machine.
Update AWS VM
Allows to update an AWS virtual machine.
Delete AWS VM
Allows to delete an AWS virtual machine.
View AWS AZ
Allows to view AWS Availability Zones.
View AWS Elastic IP
Allows to view an AWS Elastic IP.
View AWS Image
Allows to view an AWS image.
View AWS Key Pair
Allows to view AWS keypairs.
View AWS Machine Type
Allows to view AWS machine types.
View AWS Region
Allows to view AWS regions.
View AWS Role
Allows to view AWS roles.
View AWS Security Group
Allows to view an AWS security group.
View AWS Subnet
Allows to view an AWS subnet.
View AWS Volume Type
Allows to view AWS volume types.
View AWS VPC
Allows to view an AWS VPC.
Create Subnet
Allows to create a subnet.
View Subnet
Allows to view a subnet.
Update Subnet
Allows to update a subnet.
Delete Subnet
Allows to delete a subnet.
Create Blueprint
Allows to create the blueprint of an application.
View Blueprint
Allows to view the blueprint of an application.
Launch Blueprint
Allows to launch the blueprint of an application.
Clone Blueprint
Allows to clone the blueprint of an application.
Delete Blueprint
Allows to delete the blueprint of an application.
Download Blueprint
Allows to download the blueprint of an application.
Export Blueprint
Allows to export the blueprint of an application.
Import Blueprint
Allows to import the blueprint of an application.
Render Blueprint
Allows to render the blueprint of an application.
Update Blueprint
Allows to update the blueprint of an application.
Upload Blueprint
Allows to upload the blueprint of an application.
Create OVA
Allows to create an OVA.
View OVA
Allows to view an OVA.
Update OVA
Allows to update an OVA.
Delete OVA
Allows to delete an OVA.
Create Marketplace Item
Allows to create a marketplace item.
View Marketplace Item
Allows to view a marketplace item.
Update Marketplace Item
Allows to update a marketplace item.
Config Marketplace Item
Allows to configure a marketplace item.
Render Marketplace Item
Allows to render a marketplace item.
Delete Marketplace Item
Allows to delete a marketplace item.
Create Report Config
Allows to create a report_config.
View Report Config
Allows to view a report_config.
Run Report Config
Allows to run a report_config.
Share Report Config
Allows to share a report_config.
Update Report Config
Allows to update a report_config.
Delete Report Config
Allows to delete a report_config.
Create Common Report Config
Allows to create a common report_config.
View Common Report Config
Allows to view a common report_config.
Update Common Report Config
Allows to update a common report_config.
Delete Common Report Config
Allows to delete a common report_config.
Create Report Instance
Allows to create a report_instance.
View Report Instance
Allows to view a report_instance.
Notify Report Instance
Allows to notify a report_instance.
Notify Report Instance
Allows to notify a report_instance.
Share Report Instance
Allows to share a report_instance.
Delete Report Instance
Allows to delete a report_instance.
View Account
Allows to view an account.
View Project
Allows to view a project.
View User
Allows to view a user.
View User Group
Allows to view a user group.
View Name Category
Allows to view a category's name.
View Value Category
Allows to view a category's value.
View Virtual Switch
Allows to view a virtual switch.
Assigning a Role
About this task
In addition to configuring basic role maps (see Configuring Role Mapping), you can configure more precise role assignments (AHV only). To assign a role
to selected users or groups that applies just to a specified set of entities, do the
following:
Procedure
Log on to Prism Central as "admin" user or any user with "super admin"
access.
Configure Active Directory settings.
Note:
You can skip this step if an active directory is already
configured.
Go to
Prism Central Settings
>
Authentication
, click
+ New Directory
and add your
preferred active directory.
Click the hamburger menu and go to
Administration
>
Roles
.
The page displays system defined and custom roles.
Select the desired role in the roles dashboard, then click
Actions
>
Manage Assignment
.
Click
Add New
to add Active Directory based users or
user groups, or IDP users or user groups (or OUs) to this role.
Figure.
Role Assignment
Click to enlarge
You are adding users or user groups and assigning entities to the new role in
the next steps.
In the
Select Users or User Groups or OUs
field, do the
following:
Select the configured AD or IDP from the drop-down.
The drop-down displays a list of available types of user or user group
such as Local User, AD based user or user groups, or SAML based user or
user groups. Select Organizational Units or OU for AD or directories
that use SAML based IDP for authentication.
Figure.
User, User Group or OU selection
Click to enlarge
Search and add the users or groups in the
Search
User
field.
Typing few letters in the search field displays a list of users from
which you can select, and you can add multiple user names in this
field.
In the
Select Entities
field, you can provide access to
various entities. The list of available entities depends on the role selected in
Step 4.
This table lists the available entities for each role:
Individual entity (one or more clusters), All
Clusters
Prism Viewer
Individual entity (one or more clusters), All
Clusters
Custom role (User defined role)
Individual entity, In Category (only AHV VMs)
This table shows the description of each entity:
Table 2.
Description of Entities
Entity
Description
AHV VM
Allows you to manage VMs including create and edit
permission
Image
Allows you to access and manage image details
Image Placement Policy
Allows you to access and manage image placement policy
details
OVA
Allows you to view and manage OVA details
Subnets: VLAN
Allows you to view subnet details
Cluster
Allows you to view and manage details of assigned clusters
(AHV and ESXi clusters)
All Clusters
Allows you to view and manage details of all clusters
VM Recovery Points
Allows you to perform recovery operations with recovery
points.
Recovery Plan (Single PC only)
Allows you to view, validate, and test recovery plans. Also
allows you to clean up VMs created after recovery plan test.
Individual entity
Allows you to view and manage individual entities such as AHV
VM, Clusters, and Subnets:VLAN
Repeat Step 5 and Step 6 for any combination of users/entities you want to
define.
Note:
To allow users to create certain entities like a VM, you may also need to
grant them access to related entities like clusters, networks, and images
that the VM requires.
Click
Save
.
Self-Service Restore
The self-service restore (also known as file-level restore) feature allows
you to do a self-service data recovery from the Nutanix data protection recovery points with
minimal intervention. You can perform self-service data recovery on both on-prem and Xi Cloud
Services.
You must deploy NGT 2.0 or newer on guest VMs to enable self-service restore from Prism
Central. For more information about enabling and mounting NGT, see Enabling and Mounting Nutanix Guest Tools in the
Prism Web Console Guide
. When you enable self-service restore and attach a disk
by logging into the VM, you can recover files within the guest OS. If you fail to detach the
disk from the VM, the disk is detached automatically from the VM after 24 hours.
Note:
You can enable self-service restore for a guest VM through a web interface or nCLI.
NGT performs the in-guest actions For more information about in-guest actions, see Nutanix Guest Tools in the
Prism Web Console
Guide
.
Self-service restore supports
only
full snapshots generated from Asynchronous and NearSync replication
schedules.
Self-Service Restore Requirements
The requirements of self-service restore of Windows and Linux VMs are as
follows.
Self-Service Restore General Requirements
The following are the general requirements of self-service restore. Ensure that you meet
the requirements before configuring self-service restore for guest VMs.
License Requirements
The AOS license required depends on the features that you want to use. For information
about the AOS license required for self-service restore, see Software Options.
Hypervisor Requirements
AHV or ESXi
The AHV clusters must be running on AHV versions that come bundled with the supported
version of AOS.
The ESXi clusters must be running on version ESXi 6.5 GA or newer.
Nutanix Software Requirements
Prism Centrals and their registered on-prem clusters (Prism Elements) must be running the
following versions of AOS.
AOS 5.18 or newer with AHV.
AOS 5.18 or newer with ESXi.
AOS 5.19 or newer with Xi Cloud Services.
You have installed NGT 2.0 or newer. For more information about enabling and mounting
NGT, see
Enabling and Mounting Nutanix Guest Tools
in the
Prism Web
Console Guide
.
You have set
disk.enableUUID=true
in the .vmx file for the guest
VMs running on ESXi.
You have configured Nutanix recovery points by adding guest VM to an Asynchronous
protection policy.
You have attached an IDE/SCSI or SATA disk
Requirements for Guest VMs Running Windows OS
The following are the specific requirements of self-service restore for guest VMs running
Windows OS. Ensure that you meet the requirements before proceeding.
You have enough logical drive letters to bring the disk online.
You have one of the following Windows OS as the guest OS.
Windows Server 2008 R2 or newer
Windows 7 through Windows 10
Requirements for Guest VMs Running Linux OS
The following are the specific requirements of self-service restore for guest VMs running
Linux OS. Ensure that you meet the requirements before proceeding.
You have appropriate file systems to recover. Self-service restore supports only
extended file systems (ext2, ext3, and ext4) and XFS file systems.
Logical Volume Manager (LVM) disks for which the volume group corresponds to only a
single physical disk are mounted.
You have one of the following Linux OS as the guest OS.
CentOS 6.5 through 6.9 and 7.0 through 7.3
Red Hat Enterprise Linux (RHEL) 6.5 through 6.9 and 7.0 through 7.3
Oracle Linux 6.5 and 7.0
SUSE Linux Enterprise Server (SLES) 11 SP1 through 11 SP4 and 12 SP1 through 12
SP3
Ubuntu 14.04 for both AHV and ESXi
Ubuntu 16.10 for AHV only
Self-Service Restore Limitations
The limitations of self-service restore of Windows and Linux VMs are as
follows.
Self-Service Restore General Limitations
The following are the general limitations of self-service restore.
Volume groups are not supported.
Snapshots created in AOS 4.5 or later releases are only supported.
PCI and delta disks are not supported.
Limitations of Guest VMs Running Windows OS
The following are the specific limitations of self-service restore for guest VMs running
Windows OS.
File systems. Self-service restore does not support dynamic disks consisting of NTFS on
simple volumes, spanned volumes, striped volumes, mirrored volumes, and RAID-5
volumes.
Only 64-bit OSes are supported.
Self-service restore does not support disks created as Microsoft Storage Space devices
by using Microsoft Windows Server 2016 or newer.
Limitations of Guest VMs Running Linux OS
Whenever the snapshot disk has an inconsistent filesystem (as indicated by the fsck check),
the disk is only attached and not mounted.
Enabling Self-Service Restore
After enabling NGT for a guest VM, you can enable the self-service restore for that
guest VM. Also, you can enable the self-service restore for a guest VM while you are
installing NGT on that guest VM.
Before you begin
For more information, see Enabling and Mounting Nutanix Guest Tools
in the
Prism Web Console Guide
.
Ensure that you have installed and enabled NGT 2.0 or newer on the guest VM.
About this task
To enable self-service restore, perform the following procedure.
Procedure
Log on to Prism Central.
Click the hamburger icon at the top-left corner of the window. Go to
Virtual Infrastructure
>
VMs
in the left pane.
Select the guest VM where you want to enable self-service restore.
Click
Manage NGT Applications
from the
Actions
drop-down menu.
Figure.
Enabling Self-Service Restore
Click to enlarge
Note:
If the guest VM does not have NGT installed, click
Install
NGT
from the
Actions
drop-down menu
and select to enable
Self Service Restore
(SSR)
.
Click
Enable
below the
Self Service Restore
(SSR)
panel.
Click
Confirm
.
Self-service restore feature is enabled on the guest VM. You can now
restore the desired files from the guest VM.
Self-Service Restore for Windows VMs
You can restore the desired files from the guest VM through the web interface or by using the
ngtcli utility of self-service restore.
Restoring a File through Web Interface (Windows VM)
After you install NGT in the Windows guest VM, you can restore the desired files from
the VM through the web interface.
Before you begin
Ensure that you have configured your Windows VM to use NGT. For more information,
see Installing NGT on Windows Machines in the
Prism Web Console Guide
.
About this task
To restore a file in Windows guest VMs by using web interface, perform the
following.
Procedure
Log in to the guest Windows VM by using administrator credentials.
Click the
Nutanix SSR
icon on the desktop.
Type the administrator credentials of the VM.
Note:
If you use:
NETBIOS domain name in username field (for example,
domain\username
), then you will be able to
log on to SSR only if your account is explicitly added to
Administrators group on the server. If username is added to any
domain group, which is then added to Administrators group, then
logon will fail. Also, you must type NETBIOS domain name in capital
letters (domain name has to be written in the same way as you see in
the output of command
net localgroup
administrators
).
FQDN in username (for example
domain.com\username
), then you will only be
able to logon if username user is a member of the
domain
admins
group.
Note:
The snapshots that are taken for that day are displayed. You also have an
option to select the snapshots for the week, month, and the year. In
addition, you can also define a custom range of dates and select the
snapshot.
Figure.
Snapshot Selection
Click to enlarge
Select the appropriate tab,
This Week
,
This
Month
,
This Year
.
You can also customize the selection by clicking
Custom
Range
tab and selecting the date range in the
From
and
To
fields.
Select the check box of the disks that you want to attach from the
snapshot.
Select
Mount
from the
Disk Action
drop-down menu.
Figure.
Mounting of Disks
Click to enlarge
The selected disk or disks are mounted and the relevant disk label is
displayed.
Go to the attached disk label drive in the VM and restore the desired
files.
To view the list of all the mounted snapshots, select
Mounted
Snapshots
.
This page displays the original snapshot drive letters and its corresponding
current drive letters. The original drive letters get assigned to the disk at
the time of the snapshot. Mounted drive letters are on which the snapshotted
disk is mounted right now.
Figure.
List of Mounted Snapshots
Click to enlarge
To detach a disk, click the disk label and click
Unmount
.
You can unmount all the disks at once by clicking
Select
All
and then clicking
Unmount
.
To detach a disk, select the check box of the disk that you want to unmount and
then from the
Disk Action
drop-down menu, select
Unmount
.
Restoring a File through Ngtcli (Windows VM)
After you install NGT in the Windows guest VM, you can restore the desired files from
the VM through the ngtcli utility.
Before you begin
Ensure that you have configured your Windows VM to use NGT. For more information,
see Installing NGT on Windows Machines in the
Prism Web Console Guide
.
About this task
To restore a file in Windows guest VMs by using ngtcli, perform the following.
Procedure
Log in to the guest Windows VM by using administrator credentials.
Open the command prompt as an administrator.
Go to the ngtcli directory in
Program Files
>
Nutanix
.
> cd c:\Program Files\Nutanix\ngtcli
Tip:
> python ngtcli.py
creates a terminal
with auto-complete.
Run the
ngtcli.cmd
command.
List the snapshots and virtual disks that are present for the guest VM.
ngtcli> ssr ls-snaps
The snapshot ID, disk labels, logical drives, and create time of the snapshot
is displayed. You can use this information and take a decision to restore
the files from the relevant snapshot that has the data.
List the snapshots with a specific
number.
ngtcli> ssr ls-snaps snapshot-count=count_value
Replace
count_value
with the number that you want to
list.
Attach the disk from the snapshots.
ngtcli> ssr attach-disk disk-label=disk_label snapshot-id=snap_id
Replace
disk_label
with the name of the disk that you want
to attach.
Replace
snap_id
with the snapshot ID of the disk that you
want to attach.
For example, to attach a disk with snapshot ID 16353 and disk label scsi0:1,
type the folllowing command.
ngtcli> ssr attach-disk snapshot-id=16353 disk-label=scsi0:1
After successfully running the command, a new disk with label gets attached
to the guest VM.
Note:
If sufficient logical drive letters are not present,
bringing disks online action fails. In this case, you should detach the
current disk, create enough free slots by detaching other self-service
disks and reattach the disk again.
Go to the attached disk label drive and restore the desired files.
Detach a disk.
ngtcli> ssr detach-disk attached-disk-label=attached_disk_label
Replace
attached_disk_label
with the name of the disk that
you want to attach.
Note:
If the disk is not removed by the guest VM administrator, the disk is
automatically removed after 24 hours.
View all the attached disks to the VM.
ngtcli> ssr list-attached-disks
Self-Service Restore for Linux VMs
The Linux guest VM user with sudo privileges can restore the desired files from the VM
through the web interface or by using the ngtcli utility.
Restoring a File through Web Interface (Linux VM)
After you install NGT in the Linux guest VM, you can restore the desired files from
the VM through the web interface.
Ensure that you have configured your Linux VM to use NGT.
About this task
To restore a file in Linux guest VMs by using web interface, perform the
following.
Procedure
Log in to the guest Linux VM as a user with sudo privileges.
Click the
Nutanix SSR
icon on the desktop.
Type the root or sudo user credentials of the VM.
The snapshots that are taken for that day is displayed. You also have an
option to select the snapshots for the week, month, and the year. In addition,
you can also define a custom range of dates and select the snapshot. For
example, in the following figure snapshot taken on this month is
displayed.
Figure.
Snapshot Selection
Click to enlarge
Select the appropriate tab,
This Week
,
This
Month
,
This Year
.
You can also customize the selection by clicking
Custom
Range
tab and selecting the date range in the
From
and
To
fields.
Select the check box of the disks that you want to attach from the
snapshot.
Select
Mount
from the
Disk Action
drop-down menu.
The selected disk or disks are mounted and the relevant disk label is
displayed.
Figure.
Mounting of Disks
Click to enlarge
Go to the attached disk label partitions in the VM and restore the desired
files.
Note:
If the disk gets updated between the snapshots, the restore process may
not work as expected. If this scenario occurs, you need to contact support
to help with the restore process.
To view the list of all the mounted snapshots, select
Mounted
Snapshots
.
This page displays the original snapshot drive letters and its corresponding
current drive letters. The original drive letters gets assigned to the disk at
the time of the snapshot. Mounted drive letters are on which the snapshotted
disk is mounted right now.
Figure.
List of Mounted Snapshots
Click to enlarge
To detach a disk, click the disk label and click
Unmount
.
You can unmount all the disks at once by clicking
Select
All
and then clicking
Unmount
.
To detach a disk, select the check box of the disk that you want to unmount and
then from the
Disk Action
drop-down menu, select
Unmount
.
Restoring a File through Ngtcli (Linux VM)
After you install NGT in the Linux guest VM, you can restore the desired files from
the VM through the ngtcli utility.
Ensure that you have configured your Linux VM to use NGT.
About this task
To restore a file in Linux guest VMs by using ngtcli, perform the following.
Procedure
Log in to the guest Linux VM with sudo or root user credentials.
Go to the ngtcli directory.
> cd /usr/local/nutanix/ngt/ngtcli
Run the
python ngtcli.py
command.
Tip:
This command creates a terminal with auto-complete.
List the snapshots and virtual disks that are present for the guest VM.
ngtcli> ssr ls-snaps
The snapshot ID, disk labels, logical drives, and create time of the snapshot
is displayed. You can use this information and take a decision to restore
the files from the relevant snapshot that has the data.
To list the snapshots with a specific
number.
ngtcli> ssr ls-snaps snapshot-count=count_value
Replace
count_value
with the number that you want to
list.
Attach the disk from the snapshots.
ngtcli> ssr attach-disk disk-label=disk_label snapshot-id=snap_id
Replace
disk_label
with the name of the disk that you want
to attach.
Replace
snap_id
with the snapshot ID of the disk that you
want to attach.
For example, to attach a disk with snapshot ID 1343 and disk label
scsi0:2,
ngtcli> ssr attach-disk snapshot-id=1343 disk-label=scsi0:2
After successfully running the command, a new disk with new label is attached
to the guest VM.
Go to the attached disk label partition and restore the desired files.
Note:
If the disk gets updated between the snapshots, the restore process may
not work as expected. If this scenario occurs, you need to contact support
to help with the restore process.
Detach a disk.
ngtcli> ssr detach-disk attached-disk-label=attached_disk_label
Replace
attached_disk_label
with the name of the disk that
you want to attach.
For example, to remove the disk with disk label scsi0:3, type the following
command.
ngtcli> ssr detach-disk attached-disk-label=scsi0:3
Note:
If the disk is not removed by the guest VM administrator, the disk is
automatically removed after 24 hours.
View all the attached disks to the VM.
ngtcli> ssr list-attached-disks
Protection with NearSync Replication Schedule and DR (Nutanix Disaster Recovery)
NearSync replication enables you to protect your guest VMs with an RPO of as low as 1 minute.
A protection policy with a NearSync replication creates a recovery point in a minutely time
interval (between 1–15 minutes), and replicates it to the recovery AZs (AZs)
for High Availability. For guest VMs protected with NearSync replication schedule, you can
perform disaster recovery (DR) to a different Nutanix cluster at same or different AZs. In
addition to DR to Nutanix clusters of the same hypervisor type, you can also perform
cross-hypervisor disaster recovery (CHDR)—disaster recovery from AHV clusters to ESXi
clusters, or from ESXi clusters to AHV clusters.
Note:
Nutanix provides multiple DR solutions to secure your environment. See Nutanix Disaster Recovery Solutions for the detailed representation of the DR offerings of
Nutanix.
The following are the advantages of protecting your guest VMs with a NearSync replication
schedule.
Protection for the mission-critical applications. Securing your data with minimal data
loss if there is a disaster, and providing you with more granular control during the
recovery process.
No minimum network latency or distance requirements.
Low stun time for guest VMs with heavy I/O applications.
Stun time is the time of
application freeze when the recovery point is taken.
Allows resolution to a disaster event in minutes.
To implement the NearSync feature, Nutanix has introduced a technology called lightweight
snapshots (LWSs). LWS recovery points are created at the metadata level only, and they
continuously replicate incoming data generated by workloads running on the active clusters.
LWS recovery points are stored in the LWS store, which is allocated on the SSD tier. When you
configure a protection policy with a NearSync replication schedule, the system allocates the
LWS store automatically.
Note:
The maximum LWS store allocation for each node is 360 GB. For the hybrid systems, it is 7%
of the SSD capacity on that node.
Transitioning in and out of NearSync
When you create a NearSync replication schedule, the schedule remains an hourly schedule
until its transition into a minutely schedule is complete.
To transition into NearSync (minutely) replication schedule, initial seeding of the
recovery AZ with the data is performed, the recovery points are taken on an hourly basis,
and replicated to the recovery AZ. After the system determines that the recovery points
containing the seeding data have replicated within a specified amount of time (default is an
hour), the system automatically transitions the replication schedule into NearSync schedule
depending on the bandwidth and the change rate. After you transition into the NearSync
replication schedule, you can see the configured minutely recovery points in the web
interface.
The following are the characteristics of the process.
Until you are transitioned into NearSync replication schedule, you can see only the
hourly recovery points in Prism Central.
If for any reason, a guest VM transitions out of NearSync replication schedule, the
system raises alerts in the
Alerts
dashboard, and the minutely
replication schedule transitions out to the hourly replication schedule. The system
continuously tries to get into the minutely replication schedule that you have configured.
If the transition is successful, the replication schedule automatically transitions back
into NearSync, and alerts specific to this condition are raised in the
Alerts
dashboard.
To transition out of the NearSync replication schedule, you can do one of the
following.
Delete the NearSync replication schedule that you have configured.
Update the NearSync replication schedule to use an hourly RPO.
Unprotect the guest VMs.
Note:
There is no transitioning out of the NearSync replication
schedule on the addition or deletion of a guest VM.
Repeated transitioning in and out of NearSync replication schedule can occur because of the
following reasons.
LWS store usage is high.
The change rate of data is high for the available bandwidth between the primary and the
recovery AZs.
Internal processing of LWS recovery points is taking more time because the system is
overloaded.
Retention Policy
Depending on the RPO (1–15 minutes), the system retains the recovery points for a specific
time period. For a NearSync replication schedule, you can configure the retention policy for
days, weeks, or months on both the primary and recovery AZs instead of defining the number
of recovery points you want to retain. For example, if you desire an RPO of 1 minute and
want to retain the recovery points for 5 days, the retention policy works in the following
way.
For every 1 minute, a recovery point is created and retained for a maximum of 15
minutes.
Note:
The recent 15 recovery points are only visible in Prism Central and are
available for the recovery operation.
For every hour, a recovery point is created and retained for 6 hours.
One daily recovery point is created and retained for 5 days.
You can also define recovery point retention in weeks or months. For example, if you
configure a 3-month schedule, the retention policy works in the following way.
For every 1 minute, a recovery point is created and retained for 15 minutes.
For every hour, a recovery point is created and retained for 6 hours.
One daily recovery point is created and retained for 7 days.
One weekly recovery point is created and retained for 4 weeks.
One monthly recovery point is created and retained for 3 months.
Note:
You can define different retention policies on the primary and recovery AZs.
The system retains subhourly and hourly recovery points for 15 minutes and 6 hours
respectively. Maximum retention time for days, weeks, and months is 7 days, 4 weeks, and
12 months respectively.
If you change the replication schedule from an hourly schedule to a minutely schedule
(Asynchronous to NearSync), the first recovery point is not created according to the new
schedule. The recovery points are created according to the start time of the old hourly
schedule (Asynchronous). If you want to get the maximum retention for the first recovery
point after modifying the schedule, update the start time accordingly for NearSync.
The following are the specific requirements for protecting your guest VMs with NearSync
replication schedule. Ensure that you meet the following requirements in addition to the general
requirements of
Nutanix Disaster Recovery
.
For more information about the general requirements of
Nutanix Disaster Recovery
, see Nutanix Disaster Recovery Requirements.
For information about node, disk and Foundation configurations required to support NearSync
replication schedules, see On-Prem Hardware Resource Requirements.
Hypervisor Requirements
AHV or ESXi
The AHV clusters must be running on version 20190916.189 or newer.
The ESXi clusters must be running on version ESXi 6.5 GA or newer.
Nutanix Software Requirements
Each on-prem AZ must have a Leap enabled Prism Central instance.
The primary and recovery Prism Centrals and their registered Nutanix clusters must be
running the following versions of AOS.
AOS 5.17.1 or newer for DR to different Nutanix clusters at the same AZ.
AOS 5.17 or newer for DR to Nutanix clusters at the different AZs.
Guest VMs protected with NearSync replication schedule support cross-hypervisor disaster
recovery. You can perform failover (DR) to recover guest VMs from AHV clusters to ESXi
clusters or guest VMs from ESXi clusters to AHV clusters by considering the following
requirements.
Both the primary and the recovery Nutanix clusters must be running AOS 5.18 or
newer.
Install and configure Nutanix Guest Tools (NGT) on all the guest VMs. For more
information, see Enabling and Mounting Nutanix Guest Tools in
Prism Web Console Guide
.
NGT configures the guest VMs with all the
required drivers for VM portability. For more information about general NGT
requirements, see Nutanix Guest Tools Requirements and Limitations
in
Prism Web Console Guide
.
CHDR supports guest VMs with flat files only.
CHDR supports IDE/SCSI disks only.
Tip:
From AOS 5.19.1, CHDR supports SATA
disks also.
For all the non-boot SCSI disks of Windows guest VMs, set the SAN policy to
OnlineAll
so that they come online automatically.
In vSphere 6.7, guest VMs are configured with UEFI secure boot by default. Upon CHDR to
an AHV cluster, these guest VMs do not start if the host does not support the UEFI secure
boot feature. For more information about supportability of UEFI secure boot on Nutanix
clusters, see the Compatibility Matrix.
For information about operating systems that support UEFI and Secure Boot, see UEFI and Secure Boot Support for CHDR.
Nutanix does not support vSphere inventory mapping (for example, VM folder and resource
pools) when protecting workloads between VMware clusters.
Nutanix does not support vSphere snapshots or delta disk files. If you have delta disks
attached to a VM and you proceed with failover, you get a validation warning and the VM
does not recover. Contact Nutanix Support for assistance.
Table 1.
Operating Systems Supported for CHDR (Asynchronous Replication)
Operating System
Version
Requirements and limitations
Windows
Windows 2008 R2 or newer versions
Windows 7 or newer versions
Only 64-bit operating systems are supported.
Linux
CentOS 6.5 and 7.0
RHEL 6.5 or newer and RHEL 7.0 or newer.
Oracle Linux 6.5 and 7.0
Ubuntu 14.04
SLES operating system is not supported.
Additional Requirements
Both the primary and the recovery Nutanix clusters must be of minimum three-nodes.
The recovery AZ container must have as much space as the protected VMs working size
set of the primary AZ. For example, if you are protecting a VM that is using 30 GB of
space on the container of the primary AZ, the same amount of space is required on the
recovery AZ container.
Consider the following specific limitations before protecting your guest VMs with
NearSync replication schedule. These limitations are in addition to the general limitations of
Nutanix Disaster Recovery
.
For information about the general limitations of
Nutanix Disaster Recovery
, see Nutanix Disaster Recovery Limitations.
All files associated with the VMs running on ESXi must be located in the same folder as
the VMX configuration file. The files not located in the same folder as the VMX
configuration file might not recover on a recovery cluster. On recovery, the guest VM with
such files fails to start with the following error message.
Operation
failed: InternalTaskCreationFailure: Error creating host specific VM change power state
task. Error: NoCompatibleHost: No host is compatible with the virtual
machine
Deduplication enabled on storage containers having guest VMs protected with NearSync
replication schedule lowers the replication speed.
Cross hypervisor disaster recovery (CHDR) does not preserve hypervisor-specific
properties (for example, multi-writer flags, independent persistent and non-persistent
disks, changed block tracking (CBT), PVSCSI disk configurations).
On CHDR, NearSync replication schedules do not support retrieving recovery points from
the recovery AZs.
For example, if you have 1 day retention at the primary AZ and 5
days retention at the recovery AZ, and you want to go back to a recovery point from 5
days ago. NearSync replication schedule does not support replicating 5 days retention
back from the recovery AZ to the primary AZ.
Creating a Protection Policy with a NearSync Replication Schedule (Nutanix Disaster Recovery)
To protect the guest VMs in a minutely replication schedule, configure a NearSync
replication schedule while creating the protection policy. The policy takes recovery points
of the protected guest VMs in the specified time intervals (1–15 minutes) and replicates
them to the recovery AZ (AZ) for High Availability. To maintain the
efficiency of minutely replication, the protection policy allows you to configure a NearSync
replication schedule to only one recovery AZ. When creating a protection policy, you can
specify only VM categories. If you want to include VMs individually, you must first create
the protection p policy—which can also include VM categories and then include the VMs
individually in the protection policy from the
VMs
page.
Before you begin
Ensure that the primary and the recovery AHV or ESXi clusters at the same or
different AZs are NearSync capable. A cluster is NearSync capable if the capacity
of each SSD in the cluster is at least 1.2 TB.
See NearSync Replication Requirements (Nutanix Disaster Recovery) and NearSync Replication Limitations (Nutanix Disaster Recovery) before you
start.
About this task
To create a protection policy with a NearSync replication schedule, do the following
at the primary AZ. You can also create a protection policy at the recovery AZ.
Protection policies you create or update at a recovery AZ synchronize back to the
primary AZ.
Procedure
Log on to the Prism Central web console.
Click the hamburger icon at the top-left corner of the window. Go to
Policies
>
Protection Policies
in the left pane.
Figure.
Protection Policy Configuration: Protection Policies
Click to enlarge
Click
Create Protection Policy
.
Specify the following information in the
Create Protection
Policy
window.
Figure.
Protection Policy Configuration: Select Primary Location
Click to enlarge
Policy name
: Enter a name for the protection
policy.
Caution:
The name can be of only alphanumeric, dot, dash,
and underscore characters.
In the
Primary Location
pane, specify the
following information.
Location
: From the drop-down
list, select an AZ (AZ) that hosts the
guest VMs to protect.
The drop-down lists all the
AZs paired with the local AZ.
Local
AZ
represents the local AZ (Prism
Central). For your primary AZ, you can check
either the local AZ or a non-local AZ.
Cluster
: From the drop-down list,
select the cluster that hosts the guest VMs to
protect.
The drop-down lists all the Nutanix
clusters registered to Prism Central representing
the selected AZ. If you want to protect the guest
VMs from multiple Nutanix clusters in the same
protection policy, select the clusters that host
those guest VMs.
All Clusters
protects the guest VMs of all Nutanix clusters
registered to Prism Central.
Click
Save
.
Clicking
Save
activates the
Recovery Location
pane.
After saving the primary AZ configuration, you can
optionally add a local schedule to retain the
recovery points at the primary AZ.
Click
+ Add Local Schedule
if you
want to retain recovery points locally in addition to
retaining recovery points in a replication schedule
(step d.iv). For example, you can create a local
schedule to retain 15 minute recovery points locally and
also an hourly replication schedule to retain recovery
points and replicate them to a recovery AZ every 2
hours. The two schedules apply differently on the guest
VMs.
Specify the following information in the
Add Schedule
window.
Figure.
Protection Policy Configuration: Add Local
Schedule
Click to enlarge
Take Snapshot Every
:
Specify the frequency in
minutes
,
hours
,
days
, or
weeks
at which you want the
recovery points to be taken locally.
Retention Type
: Specify
one of the following two types of retention policy.
Linear
: Implements a
simple retention scheme at the local AZ. If you
set the retention number to n, the local AZ
retains the n recent recovery points.
When you
enter the frequency in minutes, the system selects
the
Roll-up
retention type
by default because minutely recovery points do not
support
Linear
retention
types.
Roll-up
: Rolls up the
recovery points into a single recovery point at
the local AZ.
For more information about the
roll-up recovery points, see step d.iii.
Retention on Local
AZ:PE_A3_AHV
: Specify the retention
number for the local AZ.
If you want to take application-consistent
recovery points, check
Take
App-Consistent Recovery
Point
.
Irrespective of the local or
replication schedules, the recovery points are of
the specified type. If you check
Take
App-Consistent Recovery Point
, the
recovery points generated are
application-consistent and if you do not check
Take App-Consistent Recovery
Point
, the recovery points generated
are crash-consistent. If the time in the local
schedule and the replication schedule match, the
single recovery point generated is
application-consistent.
Note:
See Application-consistent Recovery Point Conditions and Limitations before you take
application-consistent snapshot.
Click
Save Schedule
.
In the
Recovery Location
pane, specify the
following information.
Figure.
Protection Policy Configuration: Select Recovery
Location
Click to enlarge
Location
: From the drop-down
list, select the AZ (AZ) where you want
to replicate the recovery points.
The drop-down lists
all the AZs paired with the local AZ.
Local AZ
represents the local
AZ (Prism Central). Select
Local
AZ
if you want to configure DR to a
different Nutanix cluster at the same AZ.
If
you do not select a AZ, local recovery points that
are created by the protection policy do not
replicate automatically. You can, however, replicate
the recovery points manually and use recovery plans
to recover the guest VMs. For more information, see
Protection and Manual DR (Nutanix Disaster Recovery).
Cluster
: From the drop-down list,
select the cluster where you want to replicate the
recovery points.
The drop-down lists all the Nutanix
clusters registered to Prism Central representing
the selected AZ. You can select one cluster at the
recovery AZ. To maintain the efficiency of
minutely replication, a protection policy allows you
to configure only one recovery AZ for a NearSync
replication schedule. However, you can add another
Asynchronous replication schedule for replicating
recovery points to the same or different AZs. For
more information to add another recovery AZ with a
replication schedule, see step e.
Note:
Selecting
auto-select
from the
drop-down list replicates the recovery points to any
available cluster at the recovery AZ. Select
auto-select
from the
drop-down list only if all the clusters at the
recovery AZ are NearSync capable and are up and
running. A cluster is NearSync capable if the
capacity of each SSD in the cluster is at least 1.2
TB. All-flash clusters do not have any specific SSD
sizing requirements.
Caution:
If the primary
Nutanix cluster contains an IBM POWER Systems
server, you can replicate recovery points to an
on-prem AZ only if that on-prem AZ contains an
IBM Power Systems server.
Click
Save
.
Clicking
Save
activates the
+ Add Schedule
button
between the primary and the recovery AZ. After
saving the recovery AZ configuration, you can
optionally add a local schedule to retain the
recovery points at the recovery AZ.
Click
+ Add Local Schedule
if you
want to retain recovery points locally in addition to
retaining recovery points in a replication schedule
(step d.iv). For example, you can create a local
schedule to retain one hourly recovery points locally to
supplement the hourly replication schedule. The two
schedules apply differently on the guest VMs after
failover, when the recovery points replicate back to the
primary AZ.
Specify the following information in the
Add Schedule
window.
Figure.
Protection Policy Configuration: Add Local
Schedule
Click to enlarge
Take Snapshot Every
:
Specify the frequency in
minutes
,
hours
,
days
, or
weeks
at which you want the
recovery points to be taken locally.
Retention Type
: Specify
one of the following two types of retention policy.
Linear
: Implements a
simple retention scheme at the local AZ. If you
set the retention number to n, the local AZ
retains the n recent recovery points.
When you
enter the frequency in minutes, the system selects
the
Roll-up
retention type
by default because minutely recovery points do not
support
Linear
retention
types.
Roll-up
: Rolls up the
recovery points into a single recovery point at
the local AZ.
For more information about the
roll-up recovery points, see step d.iii.
Retention on
10.xx.xx.xxx:PE_C1_AHV
: Specify the
retention number for the local AZ.
If you want to take application-consistent
recovery points, check
Take
App-Consistent Recovery
Point
.
Irrespective of the local or
replication schedules, the recovery points are of
the specified type. If you check
Take
App-Consistent Recovery Point
, the
recovery points generated are
application-consistent and if you do not check
Take App-Consistent Recovery
Point
, the recovery points generated
are crash-consistent. If the time in the local
schedule and the replication schedule match, the
single recovery point generated is
application-consistent.
Click
Save Schedule
.
Click
+ Add Schedule
to add a replication
schedule between the primary and the recovery AZ.
Specify the following information in the
Add
Schedule
window. The window auto-populates the
Primary Location
and
Recovery
Location
that you have selected in step b and step
c.
Figure.
Protection Policy Configuration: Add Schedule
(NearSync)
Click to enlarge
Protection Type
: Click
Asynchronous
.
Take Snapshot Every
: Specify the
frequency in
minutes
(anywhere
between 1-15 minutes) at which you want the recovery
points to be taken.
The specified frequency is the
RPO. For more information about RPO, see Nutanix Disaster Recovery Terminology.
Retention Type
: When you enter
the frequency in
minutes
in step
ii, the system selects the
Roll-up
retention type by
default because NearSync replication schedules do not
support Linear retention
types.
Roll-up
retention
type rolls up the recovery points as per the RPO and
retention period into a single recovery point at a
AZ. For example, if you set the RPO to 1 hour, and
the retention time to 5 days, the 24 oldest hourly
recovery points roll up into a single daily recovery
point (one recovery point = 24 hourly recovery
points) after every 24 hours. The system keeps one
day (of rolled-up hourly recovery points) and 4 days
of daily recovery points.
Note:
If the retention period is n days, the system
keeps 1 day of RPO (rolled-up hourly recovery
points) and n-1 days of daily recovery
points.
If the retention period is n weeks, the system
keeps 1 day of RPO, 1 week of daily and n-1 weeks
of weekly recovery points.
If the retention period is n months, the
system keeps 1 day of RPO, 1 week of daily, 1
month of weekly, and n-1 months of monthly
recovery points.
If the retention period is n years, the system
keeps 1 day of RPO, 1 week of daily, 1 month of
weekly, and n-1 months of monthly recovery
points.
Note:
The recovery points that are used to
create a rolled-up recovery point are
discarded.
Tip:
Use roll-up
retention policies for anything with a longer
retention period. Roll-up policies are more
flexible and automatically handle recovery point
aging/pruning while still providing granular RPOs
for the first day.
To specify the retention number for the primary and
recovery AZs, do the following.
Retention on Local AZ:
PE_A3_AHV
: Specify the retention
number for the primary AZ.
This field is
unavailable if you do not specify a recovery
location.
Retention on
10.xx.xx.xxx:PE_C1_AHV
: Specify the
retention number for the recovery AZ.
If you want to enable reverse retention of the recovery
points, check
Reverse retention for VMs on
recovery location
.
Reverse retention
maintains the retention numbers of recovery points
even after failover to a recovery AZ in the same
or different AZs. For example, if you
retain two recovery points at the primary AZ and
three recovery points at the recovery AZ, and you
enable reverse retention, a failover event does not
change the initial retention numbers when the
recovery points replicate back to the primary AZ.
The recovery AZ still retains two recovery points
while the primary AZ retains three recovery
points. If you do not enable reverse retention, a
failover event changes the initial retention numbers
when the recovery points replicate back to the
primary AZ. The recovery AZ retains three
recovery points while the primary AZ retains two
recovery points.
Maintaining the same
retention numbers at a recovery AZ is required if
you want to retain a particular number of recovery
points, irrespective of where the guest VM is after
its failover.
If you want to take application-consistent recovery
points, check
Take App-Consistent Recovery
Point
.
Application-consistent recovery
points ensure that application consistency is
maintained in the replicated recovery points. For
application-consistent recovery points, install NGT
on the guest VMs running on AHV clusters. For guest
VMs running on ESXi clusters, you can take
application-consistent recovery points without
installing NGT, but the recovery points are
hypervisor-based, and leads to VM stuns (temporary
unresponsive VMs) after failover to the recovery
AZs.
Caution:
Application-consistent recovery points fail for
EFI-boot enabled Windows 2019 VM running on ESXi
when NGT is not installed. Nutanix recommends
installing NGT on guest VMs running on ESXi
also.
Click
Save Schedule
.
Click
+ Add Recovery Location
if you want to add
an additional recovery AZ for the guest VMs in the protection
policy.
To add an on-prem AZ for recovery, see Protection and DR between On-Prem AZs (Nutanix Disaster Recovery)
To add Xi Cloud Services for recovery, see Protection and DR between On-Prem AZ and Xi Cloud Service (Xi Leap).
Figure.
Protection Policy Configuration: Additional Recovery
Location
Click to enlarge
Click
+ Add Schedule
to add a replication
schedule between the primary AZ and the additional recovery AZ you
specified in step e.
The
Add Schedule
window shows that
auto-populates the
Primary Location
and the
additional
Recovery Location
. Perform step d
again to add the replication schedule.
By default, recovery point creation begins immediately after you
create the protection policy. If you want to specify when recovery
point creation must begin, click
Immediately
at the top-right corner, and then, in the
Start
Time
dialog box, do the following.
Click
Start protection at specific point in
time
.
Specify the time at which you want to start taking
recovery points.
Click
Save
.
Click
Next
.
Clicking
Next
shows a list of VM categories
where you can optionally check one or more VM categories to protect in
the protection policy. DR configurations using Leap allows you to
protect a guest VM by using only one protection policy. Therefore, VM
categories specified in another protection policy are not in the list.
If you protect a guest VM in another protection policy by specifying the
VM category of the guest VM (category-based inclusion), and if you
protect the guest VM from the
VMs
page in this
policy (individual inclusion), the individual inclusion supersedes the
category-based inclusion. Effectively, only the protection policy that
protected the individual guest VM protects the guest VM.
For example, the guest VM
VM_SherlockH
is in the category
Department:Admin
, and you add this category to the
protection policy named
PP_AdminVMs
. Now, if you add
VM_SherlockH
from the
VMs
page
to another protection policy named
PP_VMs_UK
,
VM_SherlockH
is protected in
PP_VMs_UK
and
unprotected from
PP_AdminVMs
.
If you want to protect the guest VMs category wise, check the VM
categories that you want to protect from the list and click
Add
.
Figure.
Protection Policy Configuration: Add VM Categories
Click to enlarge
Prism Central includes built-in VM categories for frequently
encountered applications (for example, MS Exchange and Oracle). If the
VM category or value you want is not available, first create the
category with the required values, or update an existing category so
that it has the values you require. Doing so ensures that the VM
categories and values are available for selection. You can add VMs to
the category either before or after you configure the protection policy.
If the guest VMs have a common characteristic, such as belonging to a
specific application or location, create a VM category and add the guest
VMs into the category.
If you do not want to protect the guest VMs
category wise, proceed to the next step without checking VM
categories. You can add the guest VMs individually to the protection
policy later from the
VMs
page (see Adding Guest VMs Individually to a Protection Policy).
Click
Create
.
The protection policy with a NearSync replication schedule is
created. To verify the protection policy, see the
Protection
Policies
page. If you check VM categories in step h, the
protection policy starts generating recovery points of the guest VMs in
those VM categories. To see the generated recovery points, click the
hamburger icon at the top-left corner of the window and go to
VM Recovery Points
. Click the recovery points
for its information. You can see the time estimated for the very first
replication (seeding) to the recovery AZs.
Figure.
Recovery Points Overview
Click to enlarge
Tip:
DR using Leap with a NearSync replication schedule also allows
you to recover the data of the minute just before the unplanned failover.
For example, with a 10 minutely protection policy, you can use the internal
lightweight snapshots (LWS) to recover the data of the ninth minute when
there is an unplanned failover.
Creating a Recovery Plan (Nutanix Disaster Recovery)
To orchestrate the failover of the protected guest VMs to the recovery AZ, create a
recovery plan. After a failover, a recovery plan recovers the protected guest VMs to the
recovery AZ. If you have configured two recovery AZs in a protection policy, create two
recovery plans for DR—one for recovery to each recovery AZ. The recovery plan synchronizes
continuously to the recovery AZ in a bidirectional way.
For more information about creating a recovery plan, see Creating a Recovery Plan (Nutanix Disaster Recovery).
Failover and Failback Operations (Nutanix Disaster Recovery)
You can perform test failover, planned failover, and unplanned failover of the guest
VMs protected with NearSync replication schedule across different Nutanix clusters at the same
or different on-prem AZ (AZ). The steps to perform test, planned, and unplanned
failover are largely the same irrespective of the replication schedules that protect the guest
VMs.
Refer Failover and Failback Management for test, planned, and unplanned
failover procedures.
Protection with Synchronous Replication Schedule (0 RPO) and DR
Synchronous replication enables you to protect your guest VMs with a zero recovery point
objective (0 RPO). A protection policy with Synchronous replication schedule replicates all
the writes on the protected guest VMs synchronously to the recovery AZ (AZs)
for High Availability. The policy also takes recovery points of those protected VMs every 6
hours—the first snapshot is taken immediately—for raw node (HDD+SSD) size up to 120 TB. Since
the replication is synchronous, the recovery points are crash-consistent only. For guest VMs
(AHV) protected with Synchronous replication schedule, you can perform DR only to an AHV
cluster at the same or different AZ. Replicating writes synchronously and also generating
recovery points helps to eliminate data losses due to:
Unplanned failure events (for example, natural disasters and network failure).
Planned failover events (for example, scheduled maintenance).
Nutanix recommends that the round-trip latency (RTT) between AHV clusters be less than 5 ms
for optimal performance of Synchronous replication schedules. Maintain adequate bandwidth to
accommodate peak writes and have a redundant physical network between the clusters.
To perform the replications synchronously yet efficiently, the protection policy limits you
to configure only one recovery AZ if you add a Synchronous replication schedule. If you
configure Synchronous replication schedule for a guest VM, you cannot add an Asynchronous or
NearSync schedule to the same guest VM. Similarly, if you configure an Asynchronous or a
NearSync replication schedule, you cannot add a Synchronous schedule to the same guest VM.
If you unpair the AZs while the guest VMs in the Nutanix clusters are still in
synchronization, the Nutanix cluster becomes unstable. Therefore, disable Synchronous
replication and clear stale stretch parameters if any on both the primary and recovery Prism
Element before unpairing the AZs. For more information about disabling Synchronous
replication, see Synchronous Replication Management.
Note:
Nutanix provides multiple disaster recovery (DR) solutions to secure your environment. See
Nutanix Disaster Recovery Solutions for the detailed representation of the DR
offerings of Nutanix.
Synchronous Replication Requirements
The following are the specific requirements for protecting your AHV guest VMs with
Synchronous replication schedule. Ensure that you meet the following requirements in addition to
the general requirements of Leap.
For information about the general requirements of
Nutanix Disaster Recovery
, see Nutanix Disaster Recovery Requirements.
For information about node, disk and Foundation configurations required to support
Synchronous replication schedules, see On-Prem Hardware Resource Requirements.
Hypervisor Requirements
AHV
The AHV clusters must be running on version 20190916.189 or newer.
Note:
Synchronous replication schedules support only AHV.
Nutanix Software Requirements
Each on-prem availability zone (AZ) must have a Leap enabled Prism Central
instance.
The primary and recovery Nutanix Clusters can be registered with a single
Prism Central instance or each can be registered with different Prism Central
instances.
The primary and recovery Prism Central and Prism Element on the registered Nutanix
clusters must be running on the same AOS version.
AOS 5.17 or newer.
AOS 5.17.1 or newer to support Synchronous replications of UEFI secure boot enabled
guest VMs.
AOS 5.19.2 or newer for DR to an AHV cluster in the same AZ (registered to the same
Prism Central). For DR to an AHV cluster in the same AZ, Prism Central must be running
version 2021.3 or newer.
Additional Requirements
For optimal performance, maintain the round trip latency (RTT) between Nutanix clusters
to less than 5 ms. Also, maintain adequate bandwidth to accommodate peak writes and have a
redundant physical network between the clusters.
The storage container name of the protected guest VMs must be the same on both the
primary and recovery clusters. Therefore, a storage container must exist on the recovery
cluster with the same name as the one on the primary cluster. For example, if the
protected guest VMs are in the
SelfServiceContainer
storage container on the
primary cluster, there must also be a
SelfServiceContainer
storage container
on the recovery cluster.
For hardware and Foundation configurations required to support Synchronous replication
schedules, see On-Prem Hardware Resource Requirements.
The clusters on the primary AZ and the recovery AZ communicate over the ports 2030,
2036, 2073, and 2090. Ensure that these ports have open access between both the primary
and the recovery clusters (Prism Element). For the complete list of required ports, see
Port Reference.
If the primary and the recovery clusters (Prism Element) are in different subnets, open
the ports manually for communication.
Tip:
If the primary and the recovery
clusters (Prism Element) are in the same subnet, you need not open the ports
manually.
To open the ports for communication to the recovery cluster, run the following
command on all CVMs of the primary cluster.
Replace
remote_cvm_ip
with the IP address of the recovery cluster CVM.
If there are multiple CVMs, replace
remote_cvm_ip
with the IP
addresses of the CVMs separated by comma.
Replace
remote_virtual_ip
with the virtual IP address of the recovery
cluster.
To open the ports for communication to the primary cluster, run the following
command on all CVMs of the recovery cluster.
Replace
source_cvm_ip
with the IP address of the primary cluster CVM.
If there are multiple CVMs, replace
source_cvm_ip
with the IP
addresses of the CVMs separated by comma.
Replace
source_virtual_ip
with the virtual IP address of the primary
cluster.
Note:
Use the
eth0
interface only.
eth0
is the
default CVM interface that shows up when you install AOS.
Synchronous Replication Limitations
Consider the following specific limitations before protecting your guest VMs with
Synchronous replication schedule. These limitations are in addition to the general limitations
of
Nutanix Disaster Recovery
.
For information about the general limitations of Leap, see Nutanix Disaster Recovery Limitations.
You cannot restore guest VMs with incompatible GPUs at the recovery cluster.
You cannot protect guest VMs configured as part of a network function chain.
You cannot protect guest VMs with affinity policies.
You cannot resize a guest VM disk while the guest VM is in replication. See
KB-9986
for more information.
Creating a Protection Policy with the Synchronous Replication Schedule
To protect the guest VMs in an instant replication schedule, configure a Synchronous
replication schedule while creating the protection policy. The policy replicates all the
writes on the protected guest VMs synchronously to the recovery AZ (AZ) for
High Availability. For a raw node (HDD+SSD) size up to 120 TB, the policy also takes
crash-consistent recovery points of those guest VMs every 6 hours and replicates them to the
recovery AZ—the first snapshot is taken immediately. To maintain the efficiency of
synchronous replication, the protection policy allows you to add only one recovery AZ for
the protected VMs. When creating a protection policy, you can specify only VM categories. If
you want to protect guest VMs individually, you must first create the protection
policy—which can also include VM categories, and then include the guest VMs individually in
the protection policy from the
VMs
page.
Before you begin
See Synchronous Replication Requirements and
Synchronous Replication Limitations before you
start.
About this task
To create a protection policy with the Synchronous replication schedule, do the
following at the primary AZ. You can also create a protection policy at the
recovery AZ. Protection policies you create or update at a recovery AZ
synchronize back to the primary AZ.
Procedure
Log on to the Prism Central web console.
Click the hamburger icon at the top-left corner of the window. Go to
Policies
>
Protection Policies
in the left pane.
Figure.
Protection Policy Configuration: Protection Policies
Click to enlarge
Click
Create Protection Policy
.
Specify the following information in the
Create Protection
Policy
window.
Figure.
Protection Policy Configuration: Select Primary Location
Click to enlarge
Policy name
: Enter a name for the protection
policy.
Caution:
The name can be of only alphanumeric, dot, dash,
and underscore characters.
In the
Primary Location
pane, specify the
following information.
Location
: From the drop-down
list, select an AZ (AZ) that hosts the
guest VMs to protect.
The drop-down lists all the
AZs paired with the local AZ.
Local
AZ
represents the local AZ (Prism
Central). For your primary AZ, you can check
either the local AZ or a non-local AZ.
Cluster
: From the drop-down list,
select the AHV cluster that hosts the VMs to
protect.
The drop-down lists all the Nutanix
clusters registered to Prism Central representing
the selected AZ. If you want to protect the guest
VMs from multiple AHV clusters in the same
protection policy, select the AHV clusters that host
those guest VMs.
All Clusters
protects the guest VMs of all Nutanix clusters
registered to Prism Central. Select
All
Clusters
only if all the clusters are
running AHV.
Click
Save
.
Clicking
Save
activates the
Recovery Location
pane. Do
not add a local schedule to retain the recovery
points locally. To maintain the replication
efficiency, Synchronous replication allows only the
replication schedule. If you add a local schedule,
you cannot click
Synchronous
in step d.
In the
Recovery Location
pane, specify the
following information.
Figure.
Protection Policy Configuration: Select Recovery
Location
Click to enlarge
Location
: From the drop-down
list, select the AZ (AZ) where you want
to replicate the recovery points.
The drop-down lists
all the AZs paired with the local AZ.
Local AZ
represents the local
AZ (Prism Central). Select
Local
AZ
if you want to configure DR to a
different AHV cluster at the same AZ.
If you
do not select a AZ, local recovery points that are
created by the protection policy do not replicate
automatically. You can, however, replicate the
recovery points manually and use recovery plans to
recover the guest VMs. For more information, see
Protection and Manual DR (Nutanix Disaster Recovery).
Cluster
: From the drop-down list,
select the AHV cluster where you want to replicate the
guest VM writes synchronously and recovery points.
The
drop-down lists all the Nutanix clusters registered
to Prism Central representing the selected AZ. You
can select one AHV cluster at the recovery AZ. Do
not select an ESXi cluster because DR configurations
using Leap support only AHV cluster. If you select
an ESXi cluster and configure a Synchronous
replication schedule, replications
fail.
Note:
Selecting
auto-select
from the
drop-down menu replicates the recovery points to any
available cluster at the recovery AZ. Select
auto-select
from the
drop-down list only if all the clusters at the
recovery AZ are running on AHV and are up and
running.
Click
Save
.
Clicking
Save
activates the
+ Add Schedule
button
between the primary and the recovery AZ. Do not
add a local schedule to retain the recovery points
locally. To maintain the replication efficiency,
Synchronous replication allows only the replication
schedule. If you add a local schedule, you cannot
click
Synchronous
in step
d.
Click
+ Add Schedule
to add a replication
schedule between the primary and the recovery AZ.
Specify the following information in the
Add
Schedule
window. The window auto-populates the
Primary Location
and
Recovery
Location
that you have selected in step b and step
c.
Figure.
Protection Policy Configuration: Add Schedule
(Synchronous)
Click to enlarge
Protection Type
: Click
Synchronous
.
Failure Handling
: Select one of
the following options to handle failure. For example, if
the connection between the primary and the recovery AZ
breaks and VM writes on the primary cluster stops replicating.
Manual
: Select this
option if you want to resume the VM writes on the
primary AZ only when you manually disable
Synchronous replication.
Automatic
: Select this
option to resume VM writes on the primary AZ
automatically after the specified
Timeout after
seconds.
Note:
The minimum timeout period is 10
seconds. For a guest VM that is configured for AHV
Metro recovery, the timeout period specified in
the Witness configured recovery plan takes
precedence. For example, if the timeout period in
the protection policy is 10 seconds and then you
specify 40 seconds in the Witness recovery plan
(automatic), the timeout period for failure
handling shall be 40 seconds only.
Click
Save Schedule
.
Clicking
Save Schedule
disables the
+ Add Recovery Location
button at the top-right because to maintain the
efficiency of synchronous replication, the policy
allows you to add only one recovery AZ.
By default, recovery point creation begins immediately after you
create the protection policy. If you want to specify when recovery
point creation must begin, click
Immediately
at the top-right corner, and then, in the
Start
Time
dialog box, do the following.
Click
Start protection at specific point in
time
.
Specify the time at which you want to start taking
recovery points.
Click
Save
.
Click
Next
.
Clicking
Next
shows a list of VM categories
where you can optionally check one or more VM categories to protect in
the protection policy. DR configurations using Leap allows you to
protect a guest VM by using only one protection policy. Therefore, VM
categories specified in another protection policy are not in the list.
If you protect a guest VM in another protection policy by specifying the
VM category of the guest VM (category-based inclusion), and if you
protect the guest VM from the
VMs
page in this
policy (individual inclusion), the individual inclusion supersedes the
category-based inclusion. Effectively, only the protection policy that
protected the individual guest VM protects the guest VM.
For example, the guest VM
VM_SherlockH
is in the category
Department:Admin
, and you add this category to the
protection policy named
PP_AdminVMs
. Now, if you add
VM_SherlockH
from the
VMs
page
to another protection policy named
PP_VMs_UK
,
VM_SherlockH
is protected in
PP_VMs_UK
and
unprotected from
PP_AdminVMs
.
If you want to protect the guest VMs category wise, check the VM
categories that you want to protect from the list and click
Add
.
Prism Central includes built-in VM categories for frequently
encountered applications (for example, MS Exchange and Oracle). If the
VM category or value you want is not available, first create the
category with the required values, or update an existing category so
that it has the values you require. Doing so ensures that the VM
categories and values are available for selection. You can add VMs to
the category either before or after you configure the protection policy.
If the guest VMs have a common characteristic, such as belonging to a
specific application or location, create a VM category and add the guest
VMs into the category.
If you do not want to protect the guest VMs
category wise, proceed to the next step without checking VM
categories. You can add the guest VMs individually to the protection
policy later from the
VMs
page (see Adding Guest VMs Individually to a Protection Policy).
Click
Create
.
The protection policy with Synchronous replication schedule is
created. To verify the protection policy, see the
Protection
Policies
page. If you check VM categories in step f, the
protection policy starts generating recovery points of the guest VMs in
those VM categories. To see the generated recovery points, click the
hamburger icon at the top-left corner of the window and go to
VM Recovery Points
. Click the recovery points
for its information. You can see the time estimated for the very first
replication (seeding) to the recovery AZs.
Figure.
Recovery Points Overview
Click to enlarge
Creating a Recovery Plan (Nutanix Disaster Recovery)
To orchestrate the failover of the protected guest VMs to the recovery AZ, create a
recovery plan. After a failover, a recovery plan recovers the protected guest VMs to the
recovery AZ. If you have configured two recovery AZs in a protection policy, create two
recovery plans for DR—one for recovery to each recovery AZ. The recovery plan synchronizes
continuously to the recovery AZ in a bidirectional way.
For more information about creating a recovery plan, see Creating a Recovery Plan (Nutanix Disaster Recovery).
Synchronous Replication Management
Synchronous replication instantly replicates all writes on the protected guest VMs to the
recovery cluster. Replication starts when you configure a protection policy and add the guest
VMs to protect. You can manage the replication by enabling, disabling, pausing, or resuming
the Synchronous replication on the protected guest VMs from the Prism Central.
Enabling Synchronous Replication
When you configure a protection policy with Synchronous replication schedule and add
guest VMs to protect, the replication is enabled by default. However, if you have disabled
the Synchronous replication on a guest VM, you have to enable it to start
replication.
About this task
To enable Synchronous replication on a guest VM, perform the following procedure at
the primary AZ (AZ). You can also perform the following procedure
at the recovery AZ. The operations you perform at a recovery AZ synchronize back
to the primary AZ.
Procedure
Log on to the Prism Central web console.
Click the hamburger icon at the top-left corner of the window. Go to
Virtual Infrastructure
>
VMs
>
List
in the left pane.
Select the guest VMs on which you want to enable Synchronous replication.
Click
Protect
from the
Actions
drop-down menu.
Select the protection policy in the table to include the guest VMs in the
protection policy.
Click
Protect
.
Pausing Synchronous Replication
The protected guest VMs on the primary cluster stop responding when the recovery
cluster is disconnected abruptly (for example, due to network outage or internal service
crash). To come out of the unresponsive state, you can pause Synchronous replication on the
guest VMs. Pausing Synchronous replication temporarily suspends the replication state of the
guest VMs without completely disabling the replication relationship.
About this task
To pause Synchronous replication on a guest VM, perform the following procedure.
Procedure
Log on to the Prism Central web console.
Click the hamburger icon at the top-left corner of the window. Go to
Virtual Infrastructure
>
VMs
>
List
in the left pane.
Select the guest VMs on which want to pause the Synchronous replication.
Click
Pause Synchronous Replication
from the
Actions
drop-down menu.
Resuming Synchronous Replication
You can resume the Synchronous replication that you had paused to come out of the
unresponsive state of the primary cluster. Resuming Synchronous replication restores the
replication status and reconciles the state of the guest VMs. To resume Synchronous
replication on a guest VM, perform the following procedure.
Procedure
Log on to the Prism Central web console.
Click the hamburger icon at the top-left corner of the window. Go to
Virtual Infrastructure
>
VMs
>
List
in the left pane.
Select the guest VMs on which want to resume Synchronous replication.
Click
Resume Synchronous Replication
from the
Actions
drop-down menu.
Failover and Failback Operations (Nutanix Disaster Recovery)
You can perform test failover, planned failover, and unplanned failover of the guest
VMs protected with Synchronous replication schedule across the AHV clusters at the different
on-prem AZ (AZ). The steps to perform test, planned, and unplanned failover are
largely the same irrespective of the replication schedules that protects the guest VMs.
Additionally, a planned failover of the guest VMs protected with Synchronous replication
schedule also allows for live migration of the protected guest VMs.
Refer Failover and Failback Management for test, planned, and unplanned
failover procedures.
Cross-Cluster Live Migration
Planned failover of the guest VMs protected with Synchronous replication schedule supports
live migration to another AHV cluster. Live migration offers zero downtime for your
applications during a planned failover event to the recovery cluster (for example, during
scheduled maintenance).
Cross-Cluster Live Migration Requirements
The following are the specific requirements to successfully migrate your guest VMs with
Live Migration.
Ensure that you meet the following requirements in addition to the requirements of
Synchronous replication schedule (Synchronous Replication Requirements) and general
requirements of Leap (Nutanix Disaster Recovery Requirements).
Stretch L2 networks across the primary and recovery AZs.
Network stretch spans your
network across different AZs. A stretched L2 network retains the IP addresses of guest
VMs after their Live Migration to the recovery AZ.
Both the primary and recovery Nutanix clusters must have identical CPU types.
The
primary and recovery Nutanix clusters must have identical CPU feature set. If the CPU
feature sets (set of CPU flags) are unidentical, Live Migration fails.
Both the primary and recovery Nutanix clusters must run on the same AHV version.
If the primary and the recovery Nutanix clusters (Prism Element) are in different
subnets, open the ports 49250–49260 for communication. For the complete list of required
ports, see Port Reference.
Cross-Cluster Live Migration Limitations
Consider the following limitation in addition to the limitations of Synchronous replication
schedule (Synchronous Replication Limitations) and
general limitations of Leap (Nutanix Disaster Recovery Limitations) before performing
live migration of your guest VMs.
Live migration of guest VMs fails if the guest VMs are part of Flow security
policies.
Tip:
To enable the guest VMs to retain the Flow security policies
after the failover (live migration), revoke the policies on the guest VMs and
Export
them to the recovery AZ. At the recovery AZ,
Import
the policies. The guest VMs read the policies
automatically after recovery.
Performing Cross-Cluster Live Migration
If due to a planned event (for example, scheduled maintenance of guest VMs) at the
primary AZ (AZ), you want to migrate your applications to another AHV
cluster without downtime, perform a planned failover with Live Migration to the recovery
AZ.
About this task
To live migrate the guest VMs, do the following procedure at the recovery AZ.
Procedure
Log on to the Prism Central web console.
Click the hamburger icon at the top-left corner of the window. Go to
Policies
>
Recovery Plans
in the left pane.
Select a recovery plan for the failover operation.
Caution:
The
Recovery Plans
page displays
many recovery plans. Select the recovery plan that has
Stretch
Networks
. If you select a recovery plan having
Non-stretch networks
, the migration fails. For
more information about selection of stretch and non-stretch networks, see
Creating a Recovery Plan (Nutanix Disaster Recovery).
Click
Failover
from the
Actions
drop-down menu.
Specify the following information in the
Failover from Recovery
Plan
window. The window auto-populates the
Failover
From
and
Failover To
locations from the
recovery plan you select in step 3.
Note:
If you select more than one recovery plan in step 3, the
Failover
action is available only when the
selected recovery plans have the same primary and recovery locations.
Figure.
Planned Failover
Click to enlarge
Failover Type
: Click
Planned
Failover
and check
Live Migrate
VMs
.
Click
+ Add target clusters
if you want to
failover to specific clusters at the recovery AZ.
If you do not add target clusters, the recovery plan migrates the
guest VMs to any AHV cluster at the recovery AZ.
Click
Failover
.
The
Failover from Recovery Plan
dialog box lists
the errors and warnings, if any, and allows you to stop or continue the test
operation. If there are no errors or you resolve the errors in step 6, the guest
VMs migrate and start at the recovery cluster. The migration might show a
network latency of 300-600 ms. You cannot see the migrated guest VMs on the
primary cluster because those VMs come up at the recovery cluster after the
migration.
If you see errors, do the following.
To review errors or warnings, click
View Details
in the description.
Resolve the error conditions and then restart the
failover procedure.
Select one of the following.
To stop the failover operation, click
Abort
.
To continue the failover operation despite the warnings, click
Execute Anyway
.
Note:
You cannot
continue the failover operation when the validation fails
with errors.
AHV Metro (Witness Option)
The Witness option extends the capability of metro availability to AHV clusters using
Nutanix Disaster Recovery
. To automate the recovery process, the recovery
plan configuration is enhanced to automatically handle the failure execution. The Witness is a
service within Prism Central (including scale-out deployments) that monitors communication
between the metro pair of clusters (primary and recovery AHV clusters). When the communication
between both the clusters is interrupted for a configurable time interval, the service
executes an unplanned failover depending on the failure type and the actions you have
configured in the associated recovery plan.
Figure.
AHV Metro Workflow
Click to enlarge
Witness continuously reads the health status from the metro pair of AHV clusters. If the
communication between the two clusters is unavailable for a set time period, the service
pauses the Synchronous replication between the clusters. If the primary cluster is
unavailable, the service can also automatically trigger an unplanned failover automatically to
start the guest VMs specified in the Witness configured recovery plan at the recovery
cluster.
