Reviews

reviews of virtualization products

New enhancements in Runecast Analyzer 2.0

Runecast Analyzer provides proactive management for VMware environments. It discovers potential risks in the VMware environment before they can cause a major outage. In 90% of the outages with VMware environments, the root cause is based on a known issue that is already available in the VMware knowledge base. Runecast Analyzer uses information from the VMware knowledge base, security hardening guides (VMware, DISA STG and PCI-DSS), and best practices to proactively identify problems or outages before they occur.

In my last review of Runecast Analyzer I tested version 1.7 (link) with vSphere and vSAN support. The next version (1.8) included NSX-V support and a couple of weeks ago version 2.0 is of Runecast Analyzer is released. This version includes the following new enhancements.

New User Interface (UI)

Runecast Analyzer 2.0 has a complete redesigned User Interface(UI) that includes new widgets such as:

  • Historical Trending
  • Host with Most Issues

History trending

It includes historical trending for at least 3 months of vSphere, vSAN and NSX-V scan results. By default every day (this can be changed) a scan is performed against one of more vCenter environment(s). The scans contains the description, IP address and why the issues was detected. The trending information is showed in widgets in the UI.

With this functionality you can keep track how compliant you are and what progress you made to solve issues. All the detected issues are summarized in the “Issue History” widget per day or weeks.

Hosts with Most Issues

Another new widget in the UI is the “Hosts with Most Issues”. It shows which ESXi host that has the most issues and deserves the most priority to investigate.

History Analysis

History Analysis is a new functionality that helps with isolating the root cause of the reported incident as quick as possible.

The first section shows a chart with a trend of detected and fixed issues over time. There are interactive dots in the chart trend that shows  issues and details of the scan. The second section shows a table with detailed descriptions of the issues.

Within the history analysis there can be filtered on:

  • Severity (Critical, Major, Medium or Low)
  • Source ( PCIDSS, SH, BP or KB)
  • Applies to (Network, Compute, vCenter, Management or VM)
  • Products (NSX-V or vSphere)

The issue results can be compared with previous scan results and the differences are showed.

This makes the new history analysis very powerful for finding issues in the vSphere environment for example after a maintenance window when performing configuration changes.

vSphere 6.7 with vSphere HTML5 client support

Runecast Analyzer supports vSphere 6.7 and has a HTML5 web-plugin for the vSphere Client and even integrates in the NSX dashboard.

PCI-DSS compliance 

Runecast Analyzer 2.0 includes a new profile with 226 different checks for the Payment Card Industry Data Securiy Standard (PCI-DSS). The profile can be enabled and automatically checks if you are compliant with the PCI-DSS profile (Runecast Analyzer supports PCI DSS 3.2.1).

This helps with becoming PCI-DSS compliant and very helpful for companies in the financial space.

The PCI-DSS results can be easily filtered and exported in different formats (PDF, CSV or clipboard copy). This can be useful when having for example an audit.

Latest VMware Knowledge Base updates

When there are new knowledge definitions available the definition database can be (automated) updated. For example with the Spectre, Meltdown and L1TF vulnerabilities, Runecast Analyzer can quickly identify those vulnerabilities when VMware releases the KB articles.

Appliance Update

In version 2.0 of Runecast Analyzer the internal components of the appliance are updated to the latest versions (such as Ubuntu, 14.04.05 LTS, PostgreSQL 10, Apache Tomcat  9.0.10 and TLS 1.2 is used). The appliance meets the latest security compliance. The appliance and knowledge definitions can be easily updated when a new version is available.

For new users deploying a new appliance (OVF) is a piece of cake. Runecast Analyzer is installed en operational within a couple of minutes. A free Runecast Analyzer trail or demo can be requested by using the following link.

Version 2.0 of Runecast Analyzer adds great new enhancements that helps better to proactively identify problems or outages before they occur and easily check the compliance of the VMware vSphere, vSAN en NSX-V environment.

Review NAKIVO Backup & Replication v7.5 – Replication

In this part of the NAKIVO Backup & Replication review I highlight the replication feature. With the replication feature you can replicate VMs. The source VMs are copied, a VM replica is created of each and replicated to the target VMware environment (also known as the recovery site).

VM Replication protects for example against the following type of disasters:

  • Natural disasters  (earthquakes, floods, tornados etc.)
  • Data center  problems such as power losses, fire and water damage
  • Hardware problems such as host, network and storage failures
  • Human errors
  • VM failures caused by updates or patches, virus or manually removal

The replication feature can be used for business continuity as part of you’re disaster recovery plan. When a disaster occurs, the protected VM(s) can be quick failed over from the primary site to the recovery site.

When the primary site is restored the VM(s) can be failed back to the primary site.

Another use case it to use replication for migrating the VMs to a new VMware environment for example when moving from on-premises to a cloud provider.

Configuration

The configuration of the replication job can be done by using  a 7 step wizard:

1. VMs. Select the VM(s) that will be replicated.

2. Destination. Select the destination host(s) and datastores the VM(s) will be replicated to.

3. Networks. If the VM on the primary site has another network than on the recovery site you can make a mapping between them. In my test environment I have an stretched L2 network so the source and target network are the same.

4. Re-IP. With this option the replicated VMs will be mapped to a new IP address. In my test environment I have an stretched L2 network so the IP address will not change.

5. Schedule.Select the scheduling for the replication job. The VM replication will be executed at the schedules. So note that the VM(s) in primary site are not synchronous replicated.

6. Retention. Set the retention for the replicated VMs. Per VM you can have up to 30 recovery points.

7. Options. Set the options for the job.

Click on Finish & Run to start the first replication job. The VM will be replicated to the recovery site in a powered off state in the vSphere client.

Perform a VM Failover.

If a disaster occurs at the primary site or something happen with one or more protected VMs you can perform a failover from the primary to the recovery site. To perform a VM failover follow these steps using the following wizard:

In the recover menu select VM failover to replica.

1. Source. Select the VM and recovery point to use.

2. Networks. If the VM on the primary site has another network than on the recovery site you can make a mapping between them. In my test environment I have an stretched L2 network so the source and target network are the same.

3. Re-IP. With this option the replicated VMs will be mapped to a new IP address. In my test environment I have an stretched L2 network so the IP address will not change.

4. Options. In the options section enter the job name. I checked the “Power off source VMs” box to prevent IP conflicts.

Click on the “Finish & Run” button to start the recovery job. The VM in the primary site is powered off and the replica VM is powered on in the recovery site. In the vSphere client, the replica VM is running after the failover.

VM Failback.

After the disaster, the protected VMs are at the recovery site. When the infrastructure at the primary is restored you may want to return these VMs back. With the replication feature these VMs can be transferred back to the primary site. Transferring the VMs back involves performing some manual steps such as deleting the recovery job (with the keep recovered VMs option) and create a new replication job.

In a next release of NAKIVO Backup & Replication a new feature called “site recovery” will be introduced. Site recovery will enhance the replication feature with for example automated testing and workflow options. With these options you can test for example if the disaster recovery plan works as expected in a isolated environment.

Update: August 27, 2018. NAKIVO announced today version 8 with Site Recovery feature. This powerful new feature allows you to:

  • Build automated recovery workflows
  • Run one-click failover, failback, and datacenter migration
  • Perform non-disruptive recovery testing
    Make sure you meet your RTOs

More information about the Site Recovery feature can be found here link.

In the next NAKIVO Backup & Replication review I will highlight the editions, licensing and conclusion of my four reviews.

Review NAKIVO Backup & Replication v7.5 – Backup and Recovery

In this part of the NAKIVO Backup & Replication review the backup and recovery options will be highlighted.

Backup

To begin with backup and recovery we first need a backup job. Configuring a backup job contains the following five steps:

  • 1. VMs: Select the VMs to backup from the inventory of the vCenter Server or ESXi host.

  • 2. Destination: Select the destination to store the VMs. Select the onboard repository with deduplication and compression enabled for storage space savings.

  • 3. Schedule: Create one or more backup schedules

  • 4. Retention: Define the retention period for each Virtual Machine (VM). Each VM will have one or more recovery points were individual files, application object or the the entire VM can be recovered. A Grandfather-Father-Son (GFS) backup rotation scheme can be used.

  • 5. Options: Select the options for the backup job:
    • App-aware mode: Use this option for applications that require that the data is consistent such as Microsoft SQL and Exchange.
    • Change tracking: Only the blocks that are changed since the last backup will be backup ed. This will increase the backup speed.
    • Screenshot verification: After the backup of each VM it will be recovered (with the network disconnected) and a screenshot will be made after the OS is started. The screenshot will be included in the email notification or in the job report.
    • Email notifications: When the job completes the status is send by Email.
    • Transport Mode: Hot Add, SAN, LAN or automatic can be selected
    • Bandwith throttling: With bandwidth throttling you can control the amount of bandwidth that is consumed by NAKIVO Backup and Replication.

The are more options to configure, refer to the following link for all the options to configure.

In 5 easy wizzard based steps a backup job is be configured.

Reports

There are several reporting functions available such as:

  • Last run report.  Provides the status of the last run backup.
  • Point-in-time report. Provides data on a particular job run.
  • Job history report. Provides data on job runs that occurred during a specified time period.
  • Protection coverage report. Contains information about all VMs and instances protected by backup and/or replication jobs, as well as about all unprotected VMs and instances.

The “last run” report is includes information about the backup such as:

  • Summary
  • Virtual Machines
  • Target Storage
  • Alarms & Notifications

This report can be created manually or in the backup job you can specify the email address of one or more recipient(s) were the report will be send to.

When screenshot verification is used, the screenshot is also included in the report.

Restore / Recover

Appliance backup

The configuration of the NAKIVO Backup & Replication server /appliance can be secured by using the Self-backup feature. When something happen with the NAKIVO Backup & Replication server the configuration can be quickly restored on another server.

After the first backup job is finished there a multiple ways to recover VM data. The following options are available to recover data from the backups:

  • Individual files. You can recover files or folders directly from compressed and deduplicated repository.
  • Microsoft SQL Server objects. Enables browsing, searching, and recovering Microsoft SQL Server objects.
  • Microsoft Active Directory objects. Enables browsing, searching, and recovering Microsoft Active Directory objects.
  • Microsoft Exchange objects. Enables browsing, searching, and recovering Microsoft Exchange emails.
  • Export Backups. This is called “Cross-Platform Recovery” and will be handled in the next paragraph.
  • Flash VM boot. Enables to run VMware and Hyper-V VMs directly from repository without the need to recover the VMs first.
  • VM recovery from backup. Full VM recovery. When you recover a VM, a new VM is created and the “old” VM is retained.

I tested several recover options:

  • Individual files. Individual files per VM can be restored. The files can be recovered on a server (for example on the same location as deleted), downloaded to the browser or emailed. I tested to recover two PowerShell files from a VM and selected the download to browser option. The files recovery is performed in seconds.

  • VM recovery from backup. With this option one or more full VMs are recovered.  The original VM will be retained so the recovering VM will not overwrite the original VM.  The recovering VM name will append “-recovered” in the end. The recovery is fast.

  • VM Flash boot. With the VM Flash boot option it’s possible to boot VMs directly from the compressed and deduplicated repository without recovering the VMs first. This saves time and can be used for example for testing software updates. VM Flash boot uses iSCSI technology to connect VM disks stored in the backup to a target to the ESXi host. In this test I recovered two VMs in isolated network and performed a software update for testing. The changes are not written to the recovery point that i’m using. When i’m finished with testing i can discard the VMs with a single click so that all the changes are lost.

  • Cross-Platform Recovery. Cross-Platform Recovery allows exporting virtual disks to other formats such as:
    • VMDKs for VMware
    • VHD for Hyper-V
    • VDHX for Hyper-V

This allows you to recover VMs in different environments (VMware to Hyper-V and Hyper-V to VMware). In this testI exported a VMware Virtual Machine with two VMDK disks to VHDX disks with the Backup Export Wizard. The “Export backups” wizzard is used and by selecting the VM and recovery point, disks and options to start the export job.

When the export completed, I created a new VM in Hyper-V Manager and pointed to the restored VDHX disks. Then i was able to start a Hyper-V VM with the exported disks attached. Cross-Platform Recovery can be used for recover VM disks from between hypervisor such as VMware vSphere to Hyper-V and to VMware Workstation and VirtualBox.

In this part of the NAKIVO Backup & Replication review I highlighted the backup and recovery features. It was a pleasure to test the backup and recovery features because they were easy, quick and they worked out of the box without any troubleshooting skills needed. In the next review I will highlight the replication feature.