Define and differentiate Acropolis Block Services (ABS) and Acropolis File Services (AFS)

Acropolis Block Services (ABS)

  • Exposes backend DSF to external consumers via iSCSI
  • Use Cases:
    • Oracle RAC
    • MSCS
    • Containers
    • Bare-metal
    • Exchange on vSphere
  • Constructs:
    • Data Services IP: Cluster Wide VIP for iSCSI logins
    • Volume Group: iSCSI target/group of disk devices
    • Disks: Devices in Volume Group
    • Attachment: Permissions for IQN access
    • Backend = VG’s disk is just a vDisk on DSF

Path High-Availability

  • Data Services VIP leveraged for discovery
  • Single address without knowing individual CVM IP’s
  • Assigned to iSCSI master
  • In event of failure, new master elected with address
  • With this, client side MPIO is not needed
    • No need to check “enable multi-path” in Hyper-V

Multi-Pathing

  • iSCSI protocol mandates single iSCSI session/target
  • 1:1 relationship from Stargate to target
  • Virtual targets automatically created per attached initiator and assigned to VG
  • Provides iSCSI target per disk device
  • Allows each disk device to have its own iSCSI session, hosted across multiple Stargates
  • Load balancing occurs during iSCSI session establishment per target
  • Performed via hash
  • TRIM supported (UNMAP)

Acropolis File Services (AFS)

  • SMB is only supported protocol
  • File Services VMs run as agent VM’s
    • Minimum of 3 VM’s deployed by default for scale
  • Transparently deployed
  • Integrated into AD/DNS
  • During install, the following are created:
    • AD Computer Account
    • AD SPN for file server and each FSVM
    • DNS for FS pointing to all FSVM(s)
    • DNS for each FSVM
    • Each FSVM uses Acropolis Volumes API accessed via ingest iSCSI
    • Allows FSVM to connect to any iSCSI target in event of outage
  • For availability in Linux, DM-MPIO (Linux Multipathing) is leveraged within FSVM with active path set to Local CVM.
  • In event of failure, DM-MPIO will active failover path on remote CVM.
  • Each FSVM will have IP which clients use to communicate to FSVM as part of DFS.
  • In event of failure, VG and IP of failed FSVM will be taken over by another FSVM:
  • When failed FSVM comes back and is stable, it will re-take its IP and VG.

Leave a Reply

Your email address will not be published. Required fields are marked *