Demystifying the Atlantis ILIO replication host – part 2

In the first part of this article I’ve explained what Atlantis ILIO products and components there are, explained what type of Session Hosts there are and how the Replication Host works. In this part I will dive a bit deeper in the boot process and the how the hosts are managed.

Boot process

So what happens is a Session- or Replication Host starts-up? What has happened to make the datastore available for the virtual machines?

The boot process of the hosts consists of booting up the operating system (Ubuntu 8.10) , boot to Multi-user mode (runlevel 2) and finally run the /etc/rc.local script. Each Atlantis ILIO host has a specific boot process, yet they share a great similarity.

Actions

During the execution of the start-up script /etc/rc.local a number of actions are executed. In table below all actions are listed and explained.

A special thanks to Andrew Wood (Solutions Engineer @ Atlantis Computing) for providing additional information.

Similarities and differences

As explained in part 1 of this article there are different Atlantis ILIO hosts. To keep things simple we’re focusing on the “Atlantis ILIO Diskless VDI” and the “Atlantis ILIO Persistent VDI” product.

Persistent – Replication Host versus Diskless – Session Host

The start-up process of the “Atlantis ILIO Persistent VDI – Replication Host” is equal to the  ”Atlantis ILIO Diskless VDI – Session Host” , with the exception of the SnapClone restore. As already concluded in the first part the Replication Host is basically an improved Session Host, just like a session host it receives files and via a NFS mount-point and stores it on the SAN.

Atlantis SnapClone

Because the “Atlantis ILIO Diskless VDI – Session Host” only stores files in a volatile RAM disk, all changes are lost after a power-cycle. To retain the virtual machines configuration (.vmx) and hard disk (.vmdk) file an “Atlantis SnapClone” is created by the administrator once the virtual machines are created, the snapshot is restored from disk [/dev/sdb1] to memory [/dev/(z)ram0].

Persistent – Replication Host versus Persistent – Session Host

The Session- and Replication Host of the “Atlantis ILIO Persistent VDI” product again share a lot of similarities but have two differences.

1. On the Session Host a minimum speed is for RAID is configured. This command is only issued on the Session Host  because that machine uses a linux-raid (called “Atlantis FastReplication”), as explained in part 1 of this article.
2. On the Session Host the NFS Server is started after the disks are configured, where on the other hosts it is started earlier in the process. It would make more sense to me that the NFS server is started last on all hosts, but somehow Atlantis Computing choose differently.

Host management

With the introduction of Atlantis ILIO Diskless VDI centralized management of the Sessions Hosts became mandatory, primarily to create/restore SnapClones. Atlantis ILIO Center fulfilled this role and introduced health monitoring and reporting. Nonetheless the  Session Hosts could operate independently, they where isolated entities.

Session Cluster

With the introduction of the Replication Host the Sessions Host are no longer isolated entities, they have a mapping with each other. A Session Cluster maps a Replication Host to a number of Session Hosts. One Atlantis ILIO Center can manage multiple Session Clusters (if needed).

A Session Cluster increases complexity, all components needs to be aware of the mapping between the hosts:

• Each “Atlantis ILIO Persistent VDI” Session Host needs to know to what Replication Host it should connect;
• Each Replication Host should know which Session Hosts to serve a dedicated NFS mount-point;
• The Atlantis ILIO Center needs to know about the relation so it can manage cluster.

The more complex the setup gets the higher the risk is of a faulty configuration or inconsistent state of one of the hosts. Knowing how the relations of a Session Cluster are managed help prevent this situations and help you troubleshoot them.

Atlantis ILIO Center

Session Clusters are created and managed via Atlantis ILIO Center. ILIO Center uses a database to store the configuration, health state and resource usage of all hosts.

To configure a Session Cluster three databases are used:

The ILIO center database is a relational database where each table contains unique data, a row is identified with an identifier (or ID) and no data entry is redundant (in other words: a value – like a hostname – is stored in one location).

In the diagram above you can see a visual representation of the related tables and columns (not all columns are shown).  A Session Cluster is established as follows in the database:

• for each Session- or Replication host an entry is created in the [entities] table, uniquely identified with its identifier (id);
• for each Session Cluster an entry is created in the [Cluster] table. The name of the cluster (clusterName) is an internal name “Cluster16”, the cluster is mapped to the entry in the [entities] table Replication Host (persistent_entity_id);
• for each Session Host an entry is created in the [entitiesMapping] table (diskless_entity_id) to map it to the Replication Host (persistent_entity_id).

An example of a Session Cluster stored in a database:

In Session Cluster management page in Atlantis ILIO center page:

PS: The database can be accessed for monitoring purposes, though this is not officially supported. In this article it is explained how to gain access to the database.

Session Host

On start-up a Session Host needs to know to which Replication Host (or persistent node) it is mapped to in order to initiate a FastReplication (synchronization of data on SAN with RAMdisk).

Session Hosts are not depending on an active connection with ILIO center. Not having a dependency on the ILIO center has huge benefits, it can operate regardless of having an ILIO center available which is great for scalability. The downside is that the mapping with the Replication Host (including address information) is not retrieved from the ILIO center database but stored on each Session Cluster separately.

As explained in part one an “Atlantis ILIO Persistent VDI – Session Hosts” mounts the folder /persistent/persistentnode via NFS to <ip>:/exports/ILIO_VirtualDesktops/<session-host-name> . The location of the mapped Replication Host is stored in a simple (but effective) way: as a entry in the hosts file with the name “persistentnode”.

/etc/hosts

127.0.0.1 localhost ilio-sh-001
10.0.0.201 persistentnode

When a Session Host is added to a Session Cluster a process “setupDisklessNode” is executed with the following actions:

For information on your Session Host see the /var/log/ibertagent.logfile

Replication Host

An “Atlantis ILIO Persistent VDI – Replication Hosts” exposes an NFS mount-point for each Session Hosts separately (with the name of the session host). A single mount-point is provided for each Session Host to offer the best performance (each mount point has a limit of 16 outstanding I/O’s) and enable granular control of permissions.

When a Session Host is added to the the Session Cluster the Replication Host create a folder in /exports/ILIO_VirtualDesktop with the hostname of the Session Host (for example ilio-sh-001). That folder added as an NFS-mount in the /etc/exports file.

/etc/exports/

"/exports/ILIO_VirtualDesktops" *(rw,no_root_squash,no_subtree_check,async,insecure,nohide)
"/exports/ILIO_VirtualDesktops/ilio-sh-001" *(rw,no_root_squash,no_subtree_check,async,insecure,nohide)
"/exports/ILIO_VirtualDesktops/ilio-sh-002" *(rw,no_root_squash,no_subtree_check,async,insecure,nohide)
"/exports/ILIO_VirtualDesktops/ilio-sh-003" *(rw,no_root_squash,no_subtree_check,async,insecure,nohide)
"/exports/ILIO_VirtualDesktops/ilio-sh-004" *(rw,no_root_squash,no_subtree_check,async,insecure,nohide)
"/exports/ILIO_VirtualDesktops/ilio-sh-005" *(rw,no_root_squash,no_subtree_check,async,insecure,nohide)

Part three?

Do you have any questions that didn’t got answered in part one or part two (this article)?  Let me know what and maybe I’ll write another part