Επεξεργασία

Κοινή χρήση μέσω


Preview features of the Azure Application Consistent Snapshot tool

This article provides a guide on setup and usage of the new features in preview for the Azure Application Consistent Snapshot tool (AzAcSnap). For basic information about the tool, see What is the Azure Application Consistent Snapshot tool?.

The preview features provided with AzAcSnap 10 are:

  • Microsoft SQL Server
  • Azure NetApp Files backup
  • Azure managed disks

Note

Previews are provided "as is," "with all faults," and "as available," and are excluded from the service-level agreements and may not be covered by customer support. Previews are subject to the supplemental terms of use for Microsoft Azure Previews found at https://azure.microsoft.com/support/legal/preview-supplemental-terms/

Using AzAcSnap preview features

AzAcSnap preview features are offered together with generally available features. Using the preview features requires the use of the --preview command-line option. To set up and install AzAcSnap, see Get started with the Azure Application Consistent Snapshot tool.

Providing feedback

You can provide feedback on AzAcSnap, including this preview, online.

Microsoft SQL Server

Supported platforms and operating systems

Note

Support for Microsoft SQL Server is Preview feature.
This section's content supplements What is Azure Application Consistent Snapshot tool page.

New database platforms and operating systems supported with this preview release.

  • Databases
    • Microsoft SQL Server 2022 (or later) on Windows Server 2019 (or later) only is in preview.

Enable communication with database

Note

Support for Microsoft SQL Server is Preview feature.
This section's content supplements Install Azure Application Consistent Snapshot tool page. This section explains how to enable communication with the database. Ensure the database you're using is correctly selected from the tabs.

The snapshot tools issue commands to the Microsoft SQL Server database directly to enable and disable backup mode.

AzAcSnap connects directly to Microsoft SQL Server using the provided connect-string to issue SQL commands, such as ALTER SERVER CONFIGURATION SET SUSPEND_FOR_SNAPSHOT_BACKUP = ON or ALTER SERVER CONFIGURATION SET SUSPEND_FOR_SNAPSHOT_BACKUP = OFF. The connect-string will determine if the installation is on the database server or a centralized "backup" server. Typical installations of AzAcSnap would be onto the database server to ensure features such as flushing file buffers can work as expected. If AzAcSnap has been installed onto the database server, then be sure the user running azacsnap has the required permissions.

azacsnap user permissions

Refer to Get started with Azure Application Consistent Snapshot tool The azacsnap user should have permissions to put Microsoft SQL Server into backup mode, and have permissions to flush I/O buffers to the volumes configured.

Configure (.\azacsnap.exe -c configure) with the correct values for Microsoft SQL Server and test (.\azacsnap.exe -c test --test mssql) azacsnap database connectivity. Run the azacsnap test command

.\azacsnap.exe -c test --test mssql
BEGIN : Test process started for 'mssql'
BEGIN : Database tests
PASSED: Successful connectivity to MSSQL version 16.00.1115
END   : Test process complete for 'mssql'

Configuring the database

This section explains how to configure the data base.

No special database configuration is required for Microsoft SQL Server as we are using the User's local operating system environment.

Configuring AzAcSnap

This section explains how to configure AzAcSnap for the specified database.

Note

Support for Microsoft SQL Server is Preview feature.
This section's content supplements Configure Azure Application Consistent Snapshot tool website page.

Details of required values

The following sections provide detailed guidance on the various values required for the configuration file.

Microsoft SQL Server Database values for configuration

When adding a Microsoft SQL Server database to the configuration, the following values are required:

  • connectionString = The Connection String used to connect to the database. For a typical AzAcSnap installation on to the system running Microsoft SQL Server where the Database Instance is MSSQL2022 the connection string = "Trusted_Connection=True;Persist Security Info=True;Data Source=MSSQL2022;TrustServerCertificate=true".
  • instanceName = The database instance name.
  • metaDataFileLocation = The location where Microsoft SQL Server will write out the backup meta-data file (for example, "C:\MSSQL_BKP\").

Azure NetApp Files backup

When you're taking snapshots by using AzAcSnap on multiple volumes, all the snapshots have the same name by default. Due to the removal of the volume name from the resource ID hierarchy when the snapshot is archived into an Azure NetApp Files backup, you must ensure that the snapshot name is unique.

AzAcSnap can automatically ensure the use of a unique name when it creates the snapshot, by appending the volume name to the normal snapshot name. For example, for a system that has two data volumes (hanadata01, hanadata02) when you're using -c backup with --prefix daily, the complete snapshot names become daily__F2AFDF98703__hanadata01 and daily__F2AFDF98703__hanadata02.

You can enable this feature in AzAcSnap by setting "anfBackup": "renameOnly" in the configuration file, as the following snippet shows:

"anfStorage": [
  {
    "anfBackup" : "renameOnly",
    "dataVolume": [

You can also enable this feature by using azacsnap -c configure --configuration edit --configfile <configfilename>. For Enter new value for 'ANF Backup (none, renameOnly)' (current = 'none'):, enter renameOnly.

For more information about this feature, see Configure the Azure Application Consistent Snapshot tool.

Azure managed disks

Microsoft provides many storage options for deploying databases such as SAP HANA. For details about some of these options, see Azure Storage types for SAP workload. There's also a cost-conscious solution with Azure premium storage.

AzAcSnap can take application-consistent database snapshots when you deploy it on this type of architecture (that is, a virtual machine [VM] with managed disks). But the setup for this platform is slightly more complicated because in this scenario AzAcSnap takes an additional step to try and flush all I/O buffers and ensure they are written out to persistent storage. On Linux AzAcSnap will call the sync command to flush file buffers, on Windows it uses the kernel call to FlushFileBuffers, before it takes a snapshot of the managed disks in the mounted logical volumes.

Important

AzAcSnap will need appropriate operating system permissions for the volume so it can perform the flush.

Here's the architecture at a high level:

  1. Attach Azure managed disks to the VM by using the Azure portal.
  2. Create a logical volume from these managed disks.
  3. Mount the logical volume to a Linux directory.
  4. Enable communication in the same way as for Azure NetApp Files in the AzAcSnap installation.
  5. Install and configure AzAcSnap.

For more information about using Azure managed disks as a storage back end, see Configure the Azure Application Consistent Snapshot tool.

Example configuration file

Here's an example configuration file. Note the hierarchy for dataVolume, mountPoint, and azureManagedDisks.

{
  "version": "5.1 Preview",
  "logPath": "./logs",
  "securityPath": "./security",
  "comments": [],
  "database": [
    {
      "hana": {
        "serverAddress": "127.0.0.1",
        "sid": "P40",
        "instanceNumber": "00",
        "hdbUserStoreName": "AZACSNAP",
        "savePointAbortWaitSeconds": 600,
        "autoDisableEnableBackint": false,
        "storage": [
          {
            "dataVolumes": [
              {
                "mountPoint": "/hana/data",
                "aliStorageResources": [
                "azureManagedDisks": [
                  {
                    "resourceId": "/subscriptions/<sub-id>/resourceGroups/<rg-name>/providers/Microsoft.Compute/disks/<disk01>",
                    "authFile": ""
                  },
                  {
                    "resourceId": "/subscriptions/<sub-id>/resourceGroups/<rg-name>/providers/Microsoft.Compute/disks/<disk02>",
                    "authFile": ""
                  }
                ]
              }
            ]
          }
        ]
      }
    }
  ]
}

Virtual machine storage layout

The storage hierarchy looks like the following example for SAP HANA:

  • Data files for the SAP HANA database:

    /hana/data/mnt00001
    
  • Mount point:

    /dev/mapper/hanadata-hanadata on /hana/data type xfs 
    
  • Logical volume:

    lvdisplay
    
    --- Logical volume ---
    LV Path                /dev/hanadata/hanadata
    LV Name                hanadata
    VG Name                hanadata
    
  • Volume group:

    vgdisplay
    
    --- Volume group ---
    VG Name               hanadata
    System ID
    Format                lvm2
    Metadata Areas        2
    Metadata Sequence No  2
    VG Access             read/write
    VG Status             resizable
    MAX LV                0
    Cur LV                1
    Open LV               1
    Max PV                0
    Cur PV                2
    Act PV                2
    VG Size               1023.99 GiB
    
  • Physical volumes (attached Azure managed disks):

    pvdisplay
    
    --- Physical volume ---
    PV Name               /dev/sdd
    VG Name               hanadata
    PV Size               512.00 GiB / not usable 4.00 MiB
    Allocatable           yes (but full)
    PE Size               4.00 MiB
    Total PE              131071
    Free PE               0
    Allocated PE          131071
    PV UUID               K3yhxN-2713-lk4k-c3Pc-xOJQ-sCkD-8ZE6YX
    --- Physical volume ---
    PV Name               /dev/sdc
    VG Name               hanadata
    PV Size               512.00 GiB / not usable 4.00 MiB
    Allocatable           yes (but full)
    PE Size               4.00 MiB
    Total PE              131071
    Free PE               0
    Allocated PE          131071
    PV UUID               RNCylW-F3OG-G93c-1XL3-W6pw-M0XB-2mYFGV
    

Installing and setting up the Azure VM and Azure managed disks in this way follows Microsoft guidance to create Logical Volume Manager (LVM) stripes of the managed disks on the VM.

With the Azure VM set up as prescribed, AzAcSnap can take snapshots of Azure managed disks. The snapshot operations are similar to those for other storage back ends that AzAcSnap supports; for example, Azure NetApp Files or Azure Large Instances (bare metal). Because AzAcSnap communicates with Azure Resource Manager to take snapshots, it also needs a service principal with the correct permissions to take managed disk snapshots.

This capability allows customers to test AzAcSnap on a smaller system and scale up to Azure NetApp Files and/or Azure Large Instances (bare metal).

Supported azacsnap command functionality with Azure managed disks is configure, test, backup, delete, and details, but not yet restore.

Restore from an Azure managed disk snapshot

Although azacsnap is currently missing the -c restore option for Azure managed disks, it's possible to restore manually as follows:

  1. Create disks from the snapshots via the Azure portal.

    Be sure to create the disks in the same availability zone as the target VM.

  2. Connect the disks to the VM via the Azure portal.

  3. Log in to the VM as the root user and scan for the newly attached disks by using dmesg or pvscan:

    • Using dmesg:

      dmesg | tail -n30
      
      [2510054.252801] scsi 5:0:0:2: Direct-Access     Msft     Virtual Disk     1.0  PQ:0 ANSI: 5
      [2510054.262358] scsi 5:0:0:2: Attached scsi generic sg4 type 0
      [2510054.268514] sd 5:0:0:2: [sde] 1073741824 512-byte logical blocks: (550 GB/512 GiB)
      [2510054.272583] sd 5:0:0:2: [sde] 4096-byte physical blocks
      [2510054.275465] sd 5:0:0:2: [sde] Write Protect is off
      [2510054.277915] sd 5:0:0:2: [sde] Mode Sense: 0f 00 10 00
      [2510054.278566] sd 5:0:0:2: [sde] Write cache: disabled, read cache: enabled, supports DPO and FUA
      [2510054.314269] sd 5:0:0:2: [sde] Attached SCSI disk
      [2510054.573135] scsi 5:0:0:3: Direct-Access     Msft     Virtual Disk     1.0  PQ: 0 ANSI: 5
      [2510054.579931] scsi 5:0:0:3: Attached scsi generic sg5 type 0
      [2510054.584505] sd 5:0:0:3: [sdf] 1073741824 512-byte logical blocks: (550 GB/512 GiB)
      [2510054.589293] sd 5:0:0:3: [sdf] 4096-byte physical blocks
      [2510054.592237] sd 5:0:0:3: [sdf] Write Protect is off
      [2510054.594735] sd 5:0:0:3: [sdf] Mode Sense: 0f 00 10 00
      [2510054.594839] sd 5:0:0:3: [sdf] Write cache: disabled, read cache: enabled, supports DPO and FUA
      [2510054.627310] sd 5:0:0:3: [sdf] Attached SCSI disk
      
    • Using pvscan:

      saphana:~ # pvscan
      
      WARNING: scan found duplicate PVID RNCylWF3OGG93c1XL3W6pwM0XB2mYFGV on /dev/sde
      WARNING: scan found duplicate PVID K3yhxN2713lk4kc3PcxOJQsCkD8ZE6YX on /dev/sdf
      WARNING: Not using device /dev/sde for PV RNCylW-F3OG-G93c-1XL3-W6pw-M0XB-2mYFGV.
      WARNING: Not using device /dev/sdf for PV K3yhxN-2713-lk4k-c3Pc-xOJQ-sCkD-8ZE6YX.
      WARNING: PV RNCylW-F3OG-G93c-1XL3-W6pw-M0XB-2mYFGV prefers device /dev/sdc because device is used by LV.
      WARNING: PV K3yhxN-2713-lk4k-c3Pc-xOJQ-sCkD-8ZE6YX prefers device /dev/sdd because device is used by LV.
      PV /dev/sdd   VG hanadata        lvm2 [512.00 GiB / 0    free]
      PV /dev/sdc   VG hanadata        lvm2 [512.00 GiB / 0    free]
      Total: 2 [1023.99 GiB] / in use: 2 [1023.99 GiB] / in no VG: 0 [0   ]
      
  4. Import a volume group clone from the disks by using vgimportclone as the root user:

    vgimportclone --basevgname hanadata_adhoc /dev/sde /dev/sdf
    
    WARNING: scan found duplicate PVID RNCylWF3OGG93c1XL3W6pwM0XB2mYFGV on /dev/sde
    WARNING: scan found duplicate PVID K3yhxN2713lk4kc3PcxOJQsCkD8ZE6YX on /dev/sdf
    WARNING: Not using device /dev/sde for PV RNCylW-F3OG-G93c-1XL3-W6pw-M0XB-2mYFGV.
    WARNING: Not using device /dev/sdf for PV K3yhxN-2713-lk4k-c3Pc-xOJQ-sCkD-8ZE6YX.
    WARNING: PV RNCylW-F3OG-G93c-1XL3-W6pw-M0XB-2mYFGV prefers device /dev/sdc because device is used by LV.
    WARNING: PV K3yhxN-2713-lk4k-c3Pc-xOJQ-sCkD-8ZE6YX prefers device /dev/sdd because device is used by LV.
    
  5. Activate the logical volume by using pvscan and vgchange as the root user:

    pvscan --cache
    
    pvscan[23761] PV /dev/sdc online.
    pvscan[23761] PV /dev/sdd online.
    pvscan[23761] PV /dev/sde online.
    pvscan[23761] PV /dev/sdf online.
    
    vgchange -ay hanadata_adhoc
    
    1 logical volume(s) in volume group "hanadata_adhoc" now active
    
  6. Mount the logical volume as the root user.

    Use the mount -o rw,nouuid options. Otherwise, volume mounting will fail because of duplicate UUIDs (universally unique identifiers) on the VM.

    mount -o rw,nouuid /dev/hanadata_adhoc/hanadata /mnt/hanadata_adhoc
    
  7. Access the data:

    ls /mnt/hanadata_adhoc/
    
    software  write-test.txt
    

Next steps