The content of a products database can tell you a lot about the inner working of that product. The Atlantis ILIO database stores the configuration and resource usage of the different components.
Since I’m building an environment including Atlantis ILIO I thought it would be good to learn about the internals of it. Having to troubleshoot some configuration issues motivated me to see (and maybe change) the configuration. So I’m not a badass hacking the database for malicious reasons.
Atlantis ILIO center
Only the Atlantis ILIO center machine has a database, session- and replication hosts don’t. Atlantis ILIO center is the management machine that manages the Atlantis ILIO session- and replication hosts that do the actual “In-Line-Image-Optimization” work.
MySQL
The machine runs a MySQL server (version 5.1.63) with one database (or schema), called ibert. The ibert database has three users 1)
The (out-of-the-box or) default credentials of an Atlantis ILIO center machine is root/admin (username/password). The password of the root account (used for remote access via the management webpage) can easily be changed. There is no direct relation between the root user to gain access to the machine, and the root user of the ibert database. However the password of the root user in the ibert database is admin.
Access the database locally
Once you are connected to a console session (or via SSH) of the Atlantis ILIO center machine, gaining access to the ibert database is easy.
root@ilio: ~# mysql -u root -p ibert
Enter password: admin
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 644
Server version: 5.1.63-0ubuntu0.11.04.1 (Ubuntu)
Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>
Knowing that getting access to the database is that ease might got you to think “Wow! So everyone can access my ILIO database just like that?!”. Well, that’s not entirely true. The mysql daemon is configured to bind only the 127.0.0.1 (or localhost) network, external networks are unable to (see or) connect to the mysql daemon.
Also, access to the ibert database is restricted to the user root logging in from the host localhost.
mysql> show grants;
+----------------------------------------------------------------------------------------------------------------------------------------+
| Grants for root@localhost |
+----------------------------------------------------------------------------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY PASSWORD '*4ACFE3202A5FF5CF467898FC58AAB1D615029441' WITH GRANT OPTION |
+----------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
Access the database remotely
If we want to connect to the Atlantis ILIO database from a remote machine (probably with a GUI like MySQL Workbench) we need to re-configure.
my.cnf
First of all we need to enable the mysql daemon to bind to an external network. In the /etc/mysql/my.cnf file we need to change the bind-address from
bind-address = 127.0.0.1
to
#bind-address = 127.0.0.1
Tip: nano is an easy editor that is installed by default (easier than vi)
To propagate the changes the daemon needs to be restarted
/etc/init.d/mysql restart
Privileges
Now you can connect to the mysql server you need the privileges to access the ibert database from a remote host.
Although it would be possible to grant this privilege to the root account this implies a choice with two answers 1) use the default password admin and accept the consequences (insecure) or 2) change the password of the root user which results in breaking the system. Therefore its probably better to create a dedicated user for remote access with a more complex password.
This is done with the following command where we add a user iliouser with the password iliopassword.
CREATE USER 'iliouser'@'%' IDENTIFIED BY 'iliopassword';
GRANT ALL PRIVILEGES ON ibert. * TO 'iliouser'@'%';
followed by another command to propagate the changes
FLUSH PRIVILEGES;
ibert
And now you’re able to connect to the Atlantis ILIO center database from a remote machine
Where can I use it for?
So what kind of valuable information can we find in the database?
Basically everything you can see on the Atlantis ILIO Center admin page is stored in the database. This includes the configuration but also health status, alerts and resource usage. Having access to the database enables you to retrieve this information and (if reaaaaallly necessary) to change the content.
Entities
A good thing to start with is knowing what entities are. Each Atlantis ILIO session- or replication host is stored as a record in the [entities] table with a unique identifier (column id). The entity is used throughout the entire database to correlate the information with the machines.
The [entities] database contains the following columns
Name | Type | Description |
id | int(10) | The unique identifier of each entity (primary key) |
name | varchar(128) | The display name of the entity (the session- or replication host) |
euuid | varchar(64) | The GUID of the entity (not sure where it’s used) |
hv_id | int(10) | The ID of the object in the [hypervisor_objects] table |
ip_address | varchar(24) | The IPv4 address of the entity (xxx.xxx.xxx.xxx) |
admin_user_name | varchar(64) | The name of the admin account |
ilio | tinyiny(1) | Is this an ILIO machine? 0 = No, 1 = Yes |
health | smallint(5) | 00000 = Disconnected, 00001 = Healthy (more info needed) |
last_ping_time | datetime | Time of last communication |
maintenance | tinyint(1) | Is the machine in maintenance mode? 0 = No, 1 = Yes |
ilio_version | varchar(24) | The version of Ilio on the machine (as stored in /etc/ilio/release-version).
Examples “Ilio-4.0.0.1” for an Atlantis ILIO 4 replication host ”Ilio-Diskless-4.0.0.1” for an Atlantis ILIO 4 session host |
os_version | varchar(64) | The OS version of the machine. Ubuntu_8.10 is used on Atlantis ILIO 4. |
num_cpu | int(10) | The total amount of processor cores |
memory | bigint(20) | The amount of memory in bytes |
swap_size | bigint(20) | The size of the swap file in bytes |
agent_version | varchar(10) | The version of the Atlantis ILIO center agent running on the machine (4.0.1.9) |
num_disks | int(10) | The amount of disks attached to the machine |
num_network_cards | int(11) | The amount of network cards attached to the machine |
configured | tinyint(1) | [NULL] Currently not used? |
deployed | tinyint(1) | Unsure what this value does (2) |
ssh_public_key | blob | [NULL] Currently not used? |
ssh_private_key | blob | [NULL] Currently not used? |
uptime | varchar(255) | A text representation of the period the system is (or has been) up.
Examples 41 minutes 1 day 10 minutes |
last_alert_timestamp | datetime | The time and date when the last alert was raised |
health_timestamp | datetime | The time and date when the health state was changed |
deployment_type | varchar(50) | The type of deployment used on this machine
Examples diskless disk-based |
export_type | varchar(50) | The type of export used to expose the ILIO datastore
Examples nfs iscsi |
function_type | varchar(50) | A more extensive of the deployment type
Examples ”DLN” for a session host (diskless node) ”PN” for a replication host (persistent node) |
configuration_file | blob | [NULL] Currently not used? |
Monitoring
Atlantis ILIO Center has a built-in notification feature (configured via Setup > Alerts). A warning notification (CPU >90% or disk / memory / load > 80% ) and an error alert (CPU > 95% or memory / disk / load >90%) can be delivered to email and/or SNMP traps. A good basic feature
If you want more extensive information (on a per entity basis) to enhance the monitoring, or analyze trend. this can be retrieved from the database. The following tables can be interesting:
Table | Content | Used for |
alerts | Contains all alerts raised per entity including the timestamp (date/time) and the message | resource
monitoring |
cpu_usage | Contains the processor usage (in percent) for each entity.
Information is refreshed every 10 minutes (see timestamp). |
resource
monitoring |
disk_usage | Contains the disk usage for each disk (or device) including disk usage, de-duplication rate, offload capacity and compression) for each entity.
Information is refreshed every 10 minutes (see timestamp). |
resource
monitoring |
iops | Contains the IOPS for each entity including network reads/write and disk reads/writes
Information is refreshed every 10 minutes (see timestamp). |
resource
monitoring |
memory_usage | Contains the memory usage for each entity storing the memory usage in bytes.
Information is refreshed every 10 minutes (see timestamp). |
resource
monitoring |
system_load | Contains the system load for each entity for the last 1 minute, 5 minutes and 10 minutes. | resource
monitoring |
DailyCpuUsage | Contains the average processor usage of each entity aggregated per day | trend
analysis |
DailyDiskUsage | Contains the average disk usage for each disk of each entity aggregated per day | trend
analysis |
DailyIops | Contains the average IOPS for each entity aggregated per day | trend
analysis |
DailyMemoryUsage | Contains the average memory usage for each entity aggregated per day | trend
analysis |
SystemEvents | Contains all informational events (as shown in Monitor > Events) | information |
Configuration
Getting an overview of the configuration can be useful, especially when the configuration is not working as expected or when manual cleanup activities are required.
The following tables can be interesting:
Table | Content |
cluster | Contains a record for each Session Cluster (new in ILIO 4) showing the internal clustername and the ID of the replication host (persistent_entity_id) |
clusterHealth | Should show the health of the session cluster, but not sure how it is stored (info needed) |
Datastores | Contains the datastores created by the Atlantis ILIO center machine for each entity including the ID of the hypervisor (from the [Hypervisors] table) and the name, address and path of the datastore |
diskless_info | Contains the devicename + size of ramdisk and if compression is enabled for each entity running ILIO diskless |
disks | Contains the specifications (mount point, device, capacity, mount type and deduplication) of each disk per entity |
entities | Contains a record for each Atlantis ILIO session- and replication hosts (as explained above) |
entitiesMapping | Contains the mapping between the persistent entity (aka the replication host) and the diskless entity (aka the session host) |
entity_nic_info | Contains the specification (ethx, ip, netmask, gateway and configtype) for each entity |
hypervisor_objects | Contains the hypervisor objects (like group, datacenter, domain and VMs) related to the entities
Only the topology of the Atlantis ILIO VMs is stored in the database |
Hypervisors | Contains the specification of the registered hypervisor as specified in Setup > Hypervisor |
Comments
In this article I’ve shown how one can connect to the internal database of an Atlantis ILIO Center machine (called ibert), what information is stored in the database and how this might help you.
If you have any questions or remarks don’t hesitate to leave a comment below. Especially if you have additional information about the content of the database, yeahh….that would great!
Disclaimer: Changing the configuration of the machine and/or database could result in losing support from the vendor. I take no responsibility if you break the system and/or loose support.