Robin User Guide
About the Robin Cloud Platform
Robin Cloud Platform (RCP) is a pure software platform, powered by containers, enables Application-aware infrastructure, and makes your deployments faster, simpler, and more cost-effective - on-premise, in the cloud or in a hybrid environment. RCP enabled container-based, software-defined infrastructure combines storage, networking and application orchestration to create a fluid infrastructure platform that simplifies application management, consolidates workloads without compromising performance as well as predictability, and maximizes hardware utilization.
RCP turns commodity hardware into a high-performance, elastic, and agile application/database consolidation platform. RCP is designed to cater to not just stateless, but also performance and data-centric stateful applications such as Databases and Big Data clusters. Robin dramatically simplifies application and data lifecycle management with features such as one-click deploy, snapshot, clone, time travel, dynamic IOPS control, and performance guarantees.
Product and Component Description
Robin Cloud Platform (RCP) consists of three components: Application-Aware Compute, Application-Aware Scale-Out Storage and Application-Aware Manager.
Robin Application-Aware Compute
Container Technology
Robin leverages container technology to consolidate applications with complete runtime isolation. Container is a lightweight, OS-based virtualization technology that allows creation of compartmentalized and isolated application environment on top of the standard OS. Just as a hypervisor abstracts OS from the underlying hardware, containers help abstract applications from OS and everything underneath, leading to simplified application deployment and seamless portability across hardware and operating platforms.
Performance-Sensitive Workloads
Robin is the first and only product in the industry that brings application lifecycle management benefits to all types of enterprise applications – including highly performance-sensitive workloads such as databases and Big Data.
Appropriate Container Configuration
Robin’s Adaptive container technology picks the appropriate container configuration depending on the application types. Traditional applications are deployed within “system containers” to provide VM-like semantics and Robin supports the deployment of stateless microservices applications such as Docker containers.
Zero Performance Impact
When used with bare-metal servers, Robin enables “zero-performance-impact” application consolidation of databases, Hadoop clusters, and other distributed applications such as Elasticsearch, with Application lifecycle management features, resulting in significant operational efficiency gains and cost reduction.
Robin Application-Aware Scale-Out Storage
Traditional Storage technology lacks application-awareness and is not designed to handle rigors of containerized environments.
Robin Cloud Platform storage is industry’s first application-aware storage subsystems that is capable of managing and controlling storage and IO resources at per-application level. It is designed from the ground up to support agile sub-second volume creation, 100,000-plus-variable-sized volumes, and varied file systems and data protection needs of applications running within the containers. Allocation of proprietary or commodity storage to Applications is due to the Application lifecycle management capability.
Decoupled Compute and Storage
By decoupling storage from compute, Robin Cloud Platform ensures data protection against compute failure and enables seamless application mobility. As no persistent data is stored on the compute nodes, compute layer can be elastically expanded or shrunk without any data movement or copy.
Application-Driven Data Lifecycle Management
Robin’s application-centric data management approach greatly simplifies application lifecycle management. Developer can create quick application clones and snapshots for agile development and testing. Using thin provisioning, compression and copy-on-write technologies, Robin ensures that clones and snapshots are created in seconds using minuscule amount of additional storage. Even a 100TB database can be cloned in a snap using only a few GBs of additional storage.
Intelligent Data Protection
Robin “understands” the data protection needs of application components to minimize overhead and maximize performance. For instance, stateful applications such as databases are assigned “protected volumes” using replication or erasure-coding techniques whereas the stateless components, such as webservers, are allocated standard volumes.
By providing enterprise-grade data protection at the storage layer, Robin obviates the need of inefficient application-level data protection, such as 3-way replication used by Hadoop and other distributed applications. This results in 50% or more storage savings and helps improve the write performance.
Robin Application-Aware Manager
Management
Robin’s application-aware manager is the “intelligent” component of the Robin platform. This is the management component that orchestrates the entire infrastructure fabric from an application perspective and manages Big Data as well as Application lifecycle.
1-Click Deployment
Taking an application as the payload, the application-aware manager automatically decides the placement, provisions containers and storage for each application component, and configures the application – thus enabling single-click deployment of even the most complex applications.
High Availability
It also continuously monitors the entire application and infrastructure stack to automatically recover failed nodes and disks, failover applications, and ensures that each application dynamically gets adequate disk IO and network bandwidth to deliver the Application-to-Spindle QoS Guarantee.
Related Documentation
- Robin CLI Reference Guide: This guide contains technical reference to all the Robin CLI commands.
- Robin API Reference Guide: This guide contains technical reference to all the Robin API End points.
Installing and Configuring Robin
Pre-Requisites
The following are the pre-requisites for installing Robin Software.
OS version - CentOS or RHEL 7.3 server
Kernel version - 3.10.0-514.6.1.el7.x86_64
By default, CentOS and RHEL 7.3 comes with 3.10.0 Kernel. The default Kernel should be upgraded to 3.10.0-514.6.1.el7.x86_64. This can be done with the following commands.
# yum install kernel-3.10.0-514.6.1.el7.x86_64 # rebootOnce the system is rebooted, type the following command to confirm the OS/kernel version.
# uname –r # 3.10.0-514.6.1.el7.x86_64NTP should be configured and working on all the hosts that will be part of Robin Cluster.
For rest of the pre-requisites, run the pre-check script provided along with the Robin Installer. The installation process, by default, will run the pre-check routine as well, unless the –noprecheck passed as argument.
# chmod +x robin-pre-check_4.0.x-<build-number>.sh # ./robin-pre-check_4.0.x-<build-number>.sh
A set of tests would be performed that will validate the kernel version, SELinux status, swap size, etc. The installation will continue only once all the pre-requisites have been met.
If you are installing robin on VMs, please make sure that the following pre-requisites are met.
In order for Robin to discover the disks, the disk.enableUUID property should be set to true in the VM settings. If this property is not set to true 'robin drive list' will not show any drives.
If you want to connect to the Container from outside the VM host then the ‘Mac Address Changes" property should be set to Accept. If this property is set to 'Reject' the container cannot be pinged from outside the host.
In VMware, promiscuous mode must be enabled for VMnetowrk port gorup.
In HyperV, mac address spoofing must be enabled for the network adapter under advance features.
Install Instructions
Robin Installer is a script, which enables package-based installation of Robin Software. It includes Robin-specific packages as an embedded payload and can be used to setup a node as a Robin server or an agent. Package dependencies are setup to avoid installation of packages that are not needed on an agent.[]{#_Toc462871339 .anchor}
Software Download
Download the robin installer and the md5check sum file using the following links.
https://s3-us-west-2.amazonaws.com/repo.robinsystems.com/releases/3.0/robin-install_4.0.x-{build-number}.sh https://s3-us-west-2.amazonaws.com/repo.robinsystems.com/releases/3.0/robin-install_4.0.x-{build-number}.md5
Installing Robin Server
The Robin installer script contains the script and the installer payload. Once the software is downloaded, run the following command to make it executable.
# chmod +x robin-install_4.0.x-<build-number>.shssh to the machine where you want to install the robin server and run the following command.
./robin-install-src_4.0.0-58.sh new ============================================================================== Robin Pre-Installation Check ============================================================================== Checking /var/lib/docker filesystem type is xfs... /var/lib/docker is xfs [PASSED] Checking / partition utilization is less than 90%... / utilization is only at 89% [PASSED] Checking available space to extract Robin in /tmp partition... Extract directory /tmp has at least 1GB available [PASSED] Checking available space for /var partition... /var does not have at least 100GB available [WARNING] Checking if /var is mounted on / partition... /var is mounted on the same partition as root filesystem [WARNING] We recommend that /var is mounted separately from root Checking available memory/swap space... Detected 16250156 KB of system memory Minimum 8GB RAM required [PASSED] Swap space 7.87 GB is >= recommended (4 GB) [PASSED] Checking if kernel dump is enabled... Package kexec-tools is installed [PASSED] Checking if crash kernel is loaded... Crash kernel is loaded [PASSED] Checking if ntpd service is running... Service ntpd is not running or service status cannot be detected Robin requires all systems to have synced system time Using ntpd is highly recommended Service ntpd is not running [WARNING] Checking CPUs cat: /sys/devices/system/cpu/cpu0/online: No such file or directory 5/6 CPUs online [PASSED] Check if Postgresql packages are already installed... Postgresql packages not detected Check if Docker packages are already installed... Docker packages not detected Check if OpenvSwitch packages are already installed... OpenvSwitch packages not detected Check if Python3.4 packages are already installed... Python3.4 packages already installed [WARNING] Checking internet connection... Docker Hub accessible [PASSED] 8.8.8.8 accessible [PASSED] Checking /tmp folder for permissions... /tmp is writable for user root [PASSED] Check if Robin software is already installed... Robin packages not detected [PASSED] Verify kernel version... Kernel 3.10.0-514.10.2.el7.x86_64 [PASSED] Check hostname resolution... /etc/resolv.conf exists [PASSED] Checking SELinux status... SELinux is disabled [PASSED] Checking firewalls... FirewallD is not running [PASSED] Checking if system FQDN is in /etc/hosts file... Checking if localhost entry is in /etc/hosts file... /etc/hosts has localhost 127.0.0.1 entry [PASSED] Hostname eqx02-poc01-s04.robinsystems.com resolved to 10.10.1.14 [PASSED] Checking if /etc/hosts entry is in the correct format... /etc/hosts entry <ip> <fqdn> <hostname> format verified [PASSED] Checking if required network ports are in use... All required ports are available [PASSED] Checking if required PATHs are present... All required PATHs present [PASSED] Checking if network service is able to be restarted... This will not succeed if the current network configuration is invalid If connectivity is lost, please login to the system console to restore network services Restarting network (via systemctl): [ OK ] Network service was restarted successfully [PASSED] Checking for drives to use as Robin storage... Unusable drive /dev/sdc (Partitioned) [WARNING] Drives available: sda sdb sdd sde sdf sdg sdh sdi sdj sdk sdl sdm sdn 13 drive(s) available for storage [PASSED] Checking drive capacity... Storage drives with at least 10GB capacity [PASSED] Checking smartctl for storage drives... Storage drives does not have smartctl output: sda sdb sdd sde sdf sdg[WARNING]sdj sdk sdl sdm sdn Checking device drivers... Storage drives use supported device drivers [PASSED] Checking device WWNs... Storage drives have WWN [PASSED] Checking for full device paths... Storage drives have full device path [PASSED] Checking if storage drives are readable... Storage drives are readable [PASSED] ============================================================================== Robin pre-check summary ------------------------------------------------------------------------------ 6 warnings detected ------------------------------------------------------------------------------ /var does not have at least 100GB available [WARNING] /var is mounted on the same partition as root filesystem [WARNING] Service ntpd is not running [WARNING] Python3.4 packages already installed [WARNING] Unusable drive /dev/sdc (Partitioned) [WARNING] Storage drives does not have smartctl output: sda sdb sdd sde sdf sdg[WARNING]sdj sdk sdl sdm sdn ------------------------------------------------------------------------------ 28 checks passed ------------------------------------------------------------------------------ /var/lib/docker is xfs [PASSED] / utilization is only at 89% [PASSED] Extract directory /tmp has at least 1GB available [PASSED] Minimum 8GB RAM required [PASSED] Swap space 7.87 GB is >= recommended (4 GB) [PASSED] Package kexec-tools is installed [PASSED] Crash kernel is loaded [PASSED] 5/6 CPUs online [PASSED] Docker Hub accessible [PASSED] 8.8.8.8 accessible [PASSED] /tmp is writable for user root [PASSED] Robin packages not detected [PASSED] Kernel 3.10.0-514.10.2.el7.x86_64 [PASSED] /etc/resolv.conf exists [PASSED] SELinux is disabled [PASSED] FirewallD is not running [PASSED] /etc/hosts has localhost 127.0.0.1 entry [PASSED] Hostname eqx02-poc01-s04.robinsystems.com resolved to 10.10.1.14 [PASSED] /etc/hosts entry <ip> <fqdn> <hostname> format verified [PASSED] All required ports are available [PASSED] All required PATHs present [PASSED] Network service was restarted successfully [PASSED] 13 drive(s) available for storage [PASSED] NAME MODEL SIZE RO STATE TRAN MIN-IO SCHED DISC-MAX sda WDC WD4000FYYZ-0 3.7T 0 running ata 512 cfq 0B sdb WDC WD4000FYYZ-0 3.7T 0 running ata 512 cfq 0B sdd KINGSTON SKC300S 111.8G 0 running sata 512 cfq 2G sde WDC WD4000FYYZ-0 3.7T 0 running sata 512 cfq 0B sdf WDC WD4000FYYZ-0 3.7T 0 running sata 512 cfq 0B sdg WDC WD4000FYYZ-0 3.7T 0 running sas 512 deadline 0B sdh WDC WD4000FYYZ-0 3.7T 0 running sas 512 deadline 0B sdi WDC WD4000FYYZ-0 3.7T 0 running sas 512 deadline 0B sdj WDC WD4000FYYZ-0 3.7T 0 running sas 512 deadline 0B sdk WDC WD4000FYYZ-0 3.7T 0 running sas 512 deadline 0B sdl WDC WD4000FYYZ-0 3.7T 0 running sas 512 deadline 0B sdm WDC WD4000FYYZ-0 3.7T 0 running sas 512 deadline 0B sdn WDC WD4000FYYZ-0 3.7T 0 running sas 512 deadline 0B Storage drives with at least 10GB capacity [PASSED] Storage drives use supported device drivers [PASSED] Storage drives have WWN [PASSED] Storage drives have full device path [PASSED] Storage drives are readable [PASSED] ------------------------------------------------------------------------------ Required checks passed with warnings. You may continue and install Robin. It is recommended to resolve the warnings prior to installing.Do you want to ignore the warnings and proceed with install? [y/N] y ============================================================================== ============================================================================== Robin Server Installer ============================================================================== Installing Robin Server Extracting required packages . Installing the packages .............................................................................. Deploying Robin 3.0 Setting up a new Robin cluster Checking for Robin Consul configuration Detected kernel version: 3.10.0-514.10.2.el7.x86_64 Perform host setup Updating system time Setting up network Restarting network Setting up Docker Setting up Consul server Cleaning up Docker plugins Setting up Robin docker storage driver Postgres database setup completed successfully Starting Robin Watchdog Initializing Robin Server Starting Robin Server services Setting up Storage Setting up UI Starting Storage Manager Successfully completed Robin Setup Admin user is required to use the Robin Cluster Manager Would you like to create one now? [y/n] y Please enter your desired user name: robin Create a password of at least 8 characters, one number, one capital letter and one lowercase letter Password: Retype password: Successfully added user 'robin' Login to the RCM with: robin login robin Robin server installation Complete, cleaning up!Login with above user credential
# robin login robin Password: User robin is logged inVerify that the host is listed by running the following command
# robin host list Zone Id | Hostname | Version | Status | State | Resource Pool | Roles | Cores | Memory | HDD(Alloc/Total) | SSD(Alloc/Total) | Instances | Tags | Joined Time -----------+----------------------------------+----------+--------+--------+---------------+-------+-------+----------------+------------------+------------------+-----------+------+--------------------- 1517201362 | eqx02-poc01-s04.robinsystems.com | 4.0.0-58 | Ready | ONLINE | None | M* | 0/6 | 1.0 GB/15.5 GB | 0 B/43.66 TB | 0 B/111.79 GB | 0 | {} | 01/28/2018 20:49:33
Installing Robin Agents
Copy the Robin installer script to all nodes that are going to be part of robin cluster. ssh to the nodes and run the following command. The ip-address refers to the ip address of the robin management server installed in the prior section.
# robin-install-src_4.0.0-58.sh join 10.10.1.14 ============================================================================== Robin Pre-Installation Check ============================================================================== Checking /var/lib/docker filesystem type is xfs... /var/lib/docker is xfs [PASSED] Checking / partition utilization is less than 90%... / utilization is only at 50% [PASSED] Checking available space to extract Robin in /tmp partition... Extract directory /tmp has at least 1GB available [PASSED] Checking available space for /var partition... /var does not have at least 100GB available [WARNING] Checking if /var is mounted on / partition... /var is mounted on the same partition as root filesystem [WARNING] We recommend that /var is mounted separately from root Checking available memory/swap space... Detected 115341028 KB of system memory Minimum 8GB RAM required [PASSED] Swap space 4.00 GB is less than recommended (16 GB) [WARNING] Checking if kernel dump is enabled... Package kexec-tools is installed [PASSED] Checking if crash kernel is loaded... Crash kernel is loaded [PASSED] Checking if ntpd service is running... Service ntpd is running [PASSED] Checking CPUs 24/24 CPUs online [PASSED] Check if Postgresql packages are already installed... Postgresql packages not detected Check if Docker packages are already installed... Docker packages not detected Check if OpenvSwitch packages are already installed... OpenvSwitch packages not detected Check if Python3.4 packages are already installed... Python3.4 packages not detected Checking internet connection... Docker Hub accessible [PASSED] 8.8.8.8 accessible [PASSED] Checking /tmp folder for permissions... /tmp is writable for user root [PASSED] Check if Robin software is already installed... Robin packages not detected [PASSED] Verify kernel version... Kernel 3.10.0-514.21.1.el7.x86_64 [PASSED] Check hostname resolution... /etc/resolv.conf exists [PASSED] Checking SELinux status... SELinux is disabled [PASSED] Checking firewalls... FirewallD is not running [PASSED] Checking if system FQDN is in /etc/hosts file... Checking if localhost entry is in /etc/hosts file... /etc/hosts has localhost 127.0.0.1 entry [PASSED] Hostname eqx02-poc01-c02.robinsystems.com resolved to 10.10.1.22 [PASSED] Checking if /etc/hosts entry is in the correct format... /etc/hosts entry <ip> <fqdn> <hostname> format verified [PASSED] Checking if required network ports are in use... All required ports are available [PASSED] Checking if required PATHs are present... All required PATHs present [PASSED] Checking if network service is able to be restarted... This will not succeed if the current network configuration is invalid If connectivity is lost, please login to the system console to restore network services Restarting network (via systemctl): [ OK ] Network service was restarted successfully [PASSED] Checking for drives to use as Robin storage... Unusable drive /dev/sda (Partitioned) [WARNING] Drives available: sdb sdc sdd 3 drive(s) available for storage [PASSED] Checking drive capacity... Storage drives with at least 10GB capacity [PASSED] Checking smartctl for storage drives... Storage drives does not have smartctl output: sdb sdc sdd [WARNING] Checking device drivers... Storage drives use supported device drivers [PASSED] Checking device WWNs... Storage drives have WWN [PASSED] Checking for full device paths... Storage drives have full device path [PASSED] Checking if storage drives are readable... Storage drives are readable [PASSED] ============================================================================== Robin pre-check summary ------------------------------------------------------------------------------ 5 warnings detected ------------------------------------------------------------------------------ /var does not have at least 100GB available [WARNING] /var is mounted on the same partition as root filesystem [WARNING] Swap space 4.00 GB is less than recommended (16 GB) [WARNING] Unusable drive /dev/sda (Partitioned) [WARNING] Storage drives does not have smartctl output: sdb sdc sdd [WARNING] ------------------------------------------------------------------------------ 28 checks passed ------------------------------------------------------------------------------ /var/lib/docker is xfs [PASSED] / utilization is only at 50% [PASSED] Extract directory /tmp has at least 1GB available [PASSED] Minimum 8GB RAM required [PASSED] Package kexec-tools is installed [PASSED] Crash kernel is loaded [PASSED] Service ntpd is running [PASSED] 24/24 CPUs online [PASSED] Docker Hub accessible [PASSED] 8.8.8.8 accessible [PASSED] /tmp is writable for user root [PASSED] Robin packages not detected [PASSED] Kernel 3.10.0-514.21.1.el7.x86_64 [PASSED] /etc/resolv.conf exists [PASSED] SELinux is disabled [PASSED] FirewallD is not running [PASSED] /etc/hosts has localhost 127.0.0.1 entry [PASSED] Hostname eqx02-poc01-c02.robinsystems.com resolved to 10.10.1.22 [PASSED] /etc/hosts entry <ip> <fqdn> <hostname> format verified [PASSED] All required ports are available [PASSED] All required PATHs present [PASSED] Network service was restarted successfully [PASSED] 3 drive(s) available for storage [PASSED] NAME MODEL SIZE RO STATE TRAN MIN-IO SCHED DISC-MAX sdb Micron_M500_MTFD 894.3G 0 running sata 4096 cfq 2G sdc Micron_M500_MTFD 894.3G 0 running sata 4096 cfq 2G sdd INTEL SSDSA2CW16 149.1G 0 running sata 512 cfq 2G Storage drives with at least 10GB capacity [PASSED] Storage drives use supported device drivers [PASSED] Storage drives have WWN [PASSED] Storage drives have full device path [PASSED] Storage drives are readable [PASSED] ------------------------------------------------------------------------------ Required checks passed with warnings. You may continue and install Robin. It is recommended to resolve the warnings prior to installing.Do you want to ignore the warnings and proceed with install? [y/N] y ============================================================================== ============================================================================== Robin Agent Installer ============================================================================== Installing Robin Agent Extracting required packages .......................................... Installing the packages ............................................................................................................................... Deploying Robin 3.0 Setting up Robin to join an existing cluster Enter admin username for Robin: robin Enter admin password for Robin: Checking for Robin Consul configuration Detected kernel version: 3.10.0-514.21.1.el7.x86_64 Perform host setup Updating system time WARNING: Total swap space of 4.0 GB is less than the recommended swap size of 16GB. Setting up network Restarting network Setting up Docker Setting up Consul client Cleaning up Docker plugins Setting up Robin docker storage driver Starting Robin Agent services Setting up Storage Setting up UI Successfully completed Robin Setup Robin agent installation Complete, cleaning up!Run the below command to see if the host is successfully joined the robin cluster.
# robin host list Zone Id | Hostname | Version | Status | State | Resource Pool | Roles | Cores | Memory | HDD(Alloc/Total) | SSD(Alloc/Total) | Instances | Tags | Joined Time -----------+----------------------------------+----------+--------+--------+---------------+-------+-------+----------------+------------------+------------------+-----------+------+--------------------- 1517201362 | eqx02-poc01-c02.robinsystems.com | 4.0.0-58 | Ready | SYNCED | None | | 0/24 | 0 B/110.0 GB | - | 0 B/1.89 TB | 0 | {} | 01/28/2018 21:14:31 1517201362 | eqx02-poc01-s04.robinsystems.com | 4.0.0-58 | Ready | ONLINE | None | M* | 0/6 | 1.0 GB/15.5 GB | 0 B/43.66 TB | 0 B/111.79 GB | 0 | {} | 01/28/2018 20:49:33
Repeat the process for all the agent nodes.
Configuring Robin cluster (CLI)
Once you complete installing robin software on all the nodes, you need to configure the cluster before creating applications. You can configure robin cluster through CLI or through GUI (Section 3.2.1). The following steps shows how to configure the cluster from command line.
Assign resource pools
After installing the robin software on all the nodes, the next step is to assign a resource pool to the nodes. Resource pools provides resource isolation at the application level. It is a way to group certain nodes together and allocate them for some specific applications. Robin by-default creates a resource pool named ‘default’. You can create a resource pool using the following command.
# robin rpool add rpool1 Added resource pool rpool1.Run the below command to add the nodes to the resource pool we just created.
# robin host assign-rpool eqx02-poc01-s04.robinsystems.com,eqx02-poc01-s05.robinsystems.com,eqx02-poc01-c02.robinsystems.com,eqx02-poc01-c01.robinsystems.com rpool1 Submitted job '1'. Use 'robin job wait 1' to track the progressAdd Roles
The next step is to Initialize the host with the robin roles. There are Management, Compute and Storage roles. Depending on the resources you can initialize a node to have one or more of these roles. The machine where robin server is installed will be given Management role during the setup. You can provide additional roles during the initialization as shown below.
For a hybrid node, we assign both roles - Compute and Storage, while for a decoupled deployment, compute and storage nodes are assigned their namesake roles respectively.
# robin host add-role eqx02-poc01-s04.robinsystems.com Compute,Storage Submitted job '6'. Use 'robin job wait --id 6' to track the progressBefore configuring a node as hybrid or storage, it is important to validate the disks that will be used by Robin. For this you can run the command below, and validate that the types (SSD/HDD) of all disks discovered by Robin are correctly identified.
# robin drive list --host eqx02-poc01-s04.robinsystems.com Zone Id | Host | WWN | Path | Reattach | Protected | Type | Free | Capacity | AllocScore | Role | State | Status | Tags -----------+----------------------------------+--------------------------------------------+----------------------------------------------------------------------------------------------+----------+-----------+------+-----------+-----------+------------+----------+-------------+---------+------ 1517201362 | eqx02-poc01-s04.robinsystems.com | 0x50026b72420340bb-centos_dhcp--70--8-root | /dev/disk/by-id/dm-uuid-LVM-CctaojaVSs8Ny7T2V4fvEqM3SIJeSNKB9TfvQ7sDQ0Hgc7VNgKebiaYk01byRyAh | N | N | HDD | 0 B | 50.0 GB | 0 | Reserved | INIT | UNKNOWN | {} 1517201362 | eqx02-poc01-s04.robinsystems.com | 0x50026b72420340bb-centos_dhcp--70--8-swap | /dev/disk/by-id/dm-uuid-LVM-CctaojaVSs8Ny7T2V4fvEqM3SIJeSNKBGECuQSu1pYCMupB2PsTo8g7vNSYAegTy | N | N | HDD | 0 B | 7.88 GB | 0 | Reserved | INIT | UNKNOWN | {} 1517201362 | eqx02-poc01-s04.robinsystems.com | 0x50026b72420340bb-centos_dhcp--70--8-home | /dev/disk/by-id/dm-uuid-LVM-CctaojaVSs8Ny7T2V4fvEqM3SIJeSNKB7gL48v5AefCP0sFpqmB1HyZM8zXmsF0G | N | N | HDD | 0 B | 53.36 GB | 0 | Reserved | INIT | UNKNOWN | {} 1517201362 | eqx02-poc01-s04.robinsystems.com | 0x50014ee0ae6d6aa1 | /dev/disk/by-id/ata-WDC_WD4000FYYZ-01UL1B1_WD-WMC130400096 | N | N | HDD | 3.64 TB | 3.64 TB | 100 | Storage | READY | ONLINE | {} 1517201362 | eqx02-poc01-s04.robinsystems.com | 0x50014ee05917c12b | /dev/disk/by-id/ata-WDC_WD4000FYYZ-01UL1B1_WD-WMC130458130 | N | N | HDD | 3.64 TB | 3.64 TB | 100 | Storage | READY | ONLINE | {} 1517201362 | eqx02-poc01-s04.robinsystems.com | 0x50026b72420340bb | /dev/disk/by-id/ata-KINGSTON_SKC300S37A120G_50026B72420340BB | N | N | SSD | 0 B | 111.79 GB | 0 | RootDisk | INIT | UNKNOWN | {} 1517201362 | eqx02-poc01-s04.robinsystems.com | 0x50026b7242034459 | /dev/disk/by-id/ata-KINGSTON_SKC300S37A120G_50026B7242034459 | N | N | SSD | 110.84 GB | 111.79 GB | 100 | Storage | READY | ONLINE | {} 1517201362 | eqx02-poc01-s04.robinsystems.com | 0x50014ee003c2962f | /dev/disk/by-id/ata-WDC_WD4000FYYZ-01UL1B1_WD-WMC130402350 | N | N | HDD | 3.64 TB | 3.64 TB | 100 | Storage | READY | ONLINE | {} 1517201362 | eqx02-poc01-s04.robinsystems.com | 0x50014ee0ae6c1b83 | /dev/disk/by-id/ata-WDC_WD4000FYYZ-01UL1B1_WD-WMC130458915 | N | N | HDD | 3.64 TB | 3.64 TB | 100 | Storage | READY | ONLINE | {} 1517201362 | eqx02-poc01-s04.robinsystems.com | 0x50014ee003c2911f | /dev/disk/by-id/ata-WDC_WD4000FYYZ-01UL1B1_WD-WMC130402113 | N | N | HDD | 3.64 TB | 3.64 TB | 100 | Storage | READY | ONLINE | {} 1517201362 | eqx02-poc01-s04.robinsystems.com | 0x50014ee003c29edf | /dev/disk/by-id/ata-WDC_WD4000FYYZ-01UL1B1_WD-WMC130403722 | N | N | HDD | 3.64 TB | 3.64 TB | 100 | Storage | READY | ONLINE | {} 1517201362 | eqx02-poc01-s04.robinsystems.com | 0x50014ee0ae6d7c1e | /dev/disk/by-id/ata-WDC_WD4000FYYZ-01UL1B1_WD-WMC130435277 | N | N | HDD | 3.64 TB | 3.64 TB | 100 | Storage | READY | ONLINE | {} 1517201362 | eqx02-poc01-s04.robinsystems.com | 0x50014ee003c15777 | /dev/disk/by-id/ata-WDC_WD4000FYYZ-01UL1B1_WD-WMC130457644 | N | N | HDD | 3.64 TB | 3.64 TB | 100 | Storage | READY | ONLINE | {} 1517201362 | eqx02-poc01-s04.robinsystems.com | 0x50014ee003c2bc41 | /dev/disk/by-id/ata-WDC_WD4000FYYZ-01UL1B1_WD-WMC130455099 | N | N | HDD | 3.64 TB | 3.64 TB | 100 | Storage | READY | ONLINE | {} 1517201362 | eqx02-poc01-s04.robinsystems.com | 0x50014ee0ae6c4d8f | /dev/disk/by-id/ata-WDC_WD4000FYYZ-01UL1B1_WD-WMC1F1714766 | N | N | HDD | 0 B | 3.64 TB | 0 | Storage | IN_PROGRESS | UNKNOWN | {} 1517201362 | eqx02-poc01-s04.robinsystems.com | 0x50014ee05917d4ea | /dev/disk/by-id/ata-WDC_WD4000FYYZ-01UL1B1_WD-WMC130401876 | N | N | HDD | 3.64 TB | 3.64 TB | 100 | Storage | READY | ONLINE | {} 1517201362 | eqx02-poc01-s04.robinsystems.com | 0x50014ee003c2b60c | /dev/disk/by-id/ata-WDC_WD4000FYYZ-01UL1B1_WD-WMC130402819 | N | N | HDD | 3.64 TB | 3.64 TB | 100 | Storage | READY | ONLINE | {}Run the below command to see if the host is successfully initialized with the roles.
Zone Id | Hostname | Version | Status | State | Resource Pool | Roles | Cores | Memory | HDD(Alloc/Total) | SSD(Alloc/Total) | Instances | Tags | Joined Time -----------+----------------------------------+----------+--------+--------+---------------+--------+-------+-----------------+------------------+------------------+-----------+------+--------------------- 1517201362 | eqx02-poc01-c02.robinsystems.com | 4.0.0-58 | Ready | SYNCED | rpool1 | | 0/24 | 0 B/110.0 GB | - | 0 B/1.89 TB | 0 | {} | 01/28/2018 21:14:31 1517201362 | eqx02-poc01-c03.robinsystems.com | 4.0.0-58 | Ready | SYNCED | rpool1 | | 0/24 | 0 B/125.75 GB | 0 B/2.73 TB | 0 B/149.05 GB | 0 | {} | 01/28/2018 21:58:21 1517201362 | eqx02-poc01-s04.robinsystems.com | 4.0.0-58 | Ready | ONLINE | rpool1 | M*,S,C | 0/6 | 7.62 GB/15.5 GB | 0 B/43.66 TB | 0 B/111.79 GB | 0 | {} | 01/28/2018 20:49:33 1517201362 | eqx02-poc01-s05.robinsystems.com | 4.0.0-58 | Ready | SYNCED | rpool1 | | 0/6 | 0 B/15.5 GB | 0 B/43.66 TB | 0 B/111.79 GB | 0 | {} | 01/28/2018 21:57:57Add IP-pool
When creating containers, robin assigns the IP address to the container from the pool of ip addresses defined by the below command:
# robin ip-pool add p1 10.10.1.81-128 255.255.255.0 Registered IP pool p1.This command enables you to manage IP address ranges. The IP addresses to use for the containers or clusters are defined using this command.
This command creates an IP address pool with 48 addresses. The last parameter is the netmask. Please note that the subnet for the ip-pool must be present on at least one of the nodes with the compute role.
Add File Server
Add a file collection to store bundles and images required for provisioning applications. A file server is an nfs server with a volume allocated from Robin managed storage. You are required to provide a hostname, media_type (HDD / SSD) and resource pool when creating a file server. The default is set to HDD. The command is as follows:
# robin collection create eqx02-poc01-s04.robinsystems.com HDD rpool1 Submitted job '24'. Use 'robin job wait --id 24' to track the progress
Uninstall Robin
Uninstalling Robin software consists of removing all robin packages and its dependencies, removing the OVS bridge and unloading of Robin kernel modules from all nodes in the cluster. A reboot is recommended after uninstallation.
- To completely remove Robin Software, you first need to uninstall all the agent nodes, and only then can you uninstall the Robin management node. To obtain list of all hosts in the cluster, run the following command.
# robin host list- You can run the following command to uninstall the Robin Software. In case of issues, or if you have containers running on this node, pass the --force flag to the uninstallation command. This command needs to be run from the respective from which you want to uninstall the robin software.
./robin-install_4.0.x-<build-number>.sh uninstall
Robin Installer
.........
Starting Robin agent uninstall
Stopping Robin Agent
Stopping Consul Client
Cleaning up node
Destroying vblock devices
Removing OVS bridge
Successfully removed the OVS bridge.
Removing configuration files
Unloading Robin kernel modules
Uninstalling Robin agent and related packages
...............................................................
Successfully uninstalled Robin agent.
It is recommended to reboot the system.Installing and Configuring Robin USING gorobin
About The gorobin Utility
"gorobin" is a command line utility provided by Robin to automate the deployment of Robin cluster on AWS. gorobin provisions EC2 and EBS resources based on Robin edition selected (DE/CE). It installs Robin cluster, and configures for use. The end result is a URL and login credentials for the Robin cluster. This guide will help you set up and run gorobin with any required custom settings. If you have any difficulties after using this guide, please contact support@robinsystems.com for additional help.
Prerequisites
The following are the prerequisites for running gorobin. Please make sure that you are in the same region as you selected for the robin install when you collect the following parameters. For example, key pairs and security groups name will differ based on the AWS region.
- Amazon's Access-Key
- Amazon’s Secret-Key
- The Region Key Pairs for the region where you want to deploy the Robin Cloud Platform.
- Region Security Group Name (use default if there is no name)
Download
Download the gorobin file from the robin portal. There is a file for MacOS and Linux. If you are using Windows or otherwise prefer to install using Docker engine, this guide will help you build the full install command. However, you will need to have Docker engine installed and use the command line in the download page instead of the command line in this document.
Using gorobin
The gorobin command line uses user specific parameters to help set up the platform. Robin will provide values for some of the mandatory parameters, while the user specific and optional parameters need to be defined by the user. The complete list of parameters is found in this section.
Values Pre-Populated by Robin:
The following value is created by Robin during the registration process.
- –install-key
Mandatory values:
You must add the following mandatory values need command line replacing the whole string <[value name]>
- –ami (The AMI is region specific. If you wish to change your region, you can find the correct AMI in the AWS console by first selecting your desired region then navigating to Images AMIs Public AMIs Searching for Robin selecting the correct edition AMI (CE = Community Edition, DE = Developer Edition). Please note, you will need to also change the region, zone, and get region specific values for Key Pairs and Security Group Names in the next subsection.
- –region
- –zone
- –access-key
- –secret-key
- –pem-keyname – This is the Key Pair file you download from your AWS console. The Key Pair is region specific. It will need to be located in the current user’s .ssh directory. For example, ~/.ssh/.pem You will need to change the permissions for the file to read-only using chmod 400 .pem
- –security-group name This is the region-specific security group name. The default for is default which will be used if you have not changed the name. You will also need to change the settings to allow SSH traffic as described in the following subsection 2.3.3.
SSH
To set up the EC2 Instances, you will need to verify that “All traffic” is allowed for the security group that you selected for both “Inbound” and “Outbound” in addition to changing the “Source” to 0.0.0.00 for both.
Both “Inbound” and “Outbound” Settings are found by navigating to the Security Group Settings in the AWS --> EC2 Settings. Select the relevant security group then in the Security Group information below select Inbound --> edit and set
- Protocol = All
- Port Range = All
- Source or Destination = 0.0.0.00
Inbound security settings:
Outbound Security settings
Optional Parameters:
The following are optional. If the values are not provided by the user robin will use the defaults
- --instance-type (default: m4.2xlarge)
- --instance-count (1 for DE and maximum 5 for CE. The DE count cannot not be changed. However you can use this parameter to decrease the number of instances automatically deployed for the Community Edition. However, for the best experience do not use a value of less than 3 for the Community Edition)
- --volume-type (default: gp2)
- --volume-size (default: 200GB)
- --volume-count (default: 3)
Example
The following example will create a 3 node Robin Cloud Platform Community Edition cluster using EC2 m4.2xlarge instances with one 500GB EBS storage on each node. The command line code is as follows with the values represented by <> being user propagated values. The values in italics are option parameters used for this example.
. /gorobin --install-key <XXXXXXXXXX> --region <region name> --zone <zone name> --ami <ami name> --security-group <region security group name> --pem-keyname <region pair key name> --access-key <IAM account access key> --secret-key <IAM account secret key> --instance-type m4.2xlarge --instance-count 3 --volume-count 1 –volume-type gp2 --volume-size 500gThe following is the command line running the above code and showing the gorobin output.
# ./gorobin_3.0.5-223 --access-key xxxxxxxxxxxxxxxxxx --secret-key xxxxxxxxxxxxxx --region us-west-1 --ami ami-3ddcf35d --pem-keyname xxxxxxxxxxxx --pem-keyfile xxxxxxxxxx --instance-type m4.2xlarge --instance-count 3 --volume-count 1 --volume-type gp2 --volume-size 500G --install-key xxxxxxxxxxxxxxxxxxxx --zone us-west-1a --security-group default
- Creating 3 EC2 instances of type 'm4.2xlarge' ... DONE (17 secs)
- Attaching 1x500.0 GiB EBS volumes to 'ec2-54-183-236-14' ... DONE (5 secs)
- Attaching 1x500.0 GiB EBS volumes to 'ec2-54-215-134-203' ... DONE (5 secs)
- Attaching 1x500.0 GiB EBS volumes to 'ec2-54-183-234-93' ... DONE (0 secs)
- Finalizing AWS Configuration ... DONE (1 secs)
- Checking network connectivity to host 'i-0134c468cdede0be2' 'ec2-54-215-134-203' ... DONE (8 secs)
- Checking network connectivity to host 'i-00bb4642b40337ed2' 'ec2-54-183-234-93' ... DONE (0 secs)
- Checking network connectivity to host 'i-0eed2e10c36ba16bf' 'ec2-54-183-236-14' ... DONE (0 secs)
- Configuring 'ec2-54-215-134-203' as Master Node of cluster ... DONE (171 secs)
- Adding '2' additional nodes to cluster ... DONE (150 secs)
- Initializing Compute and Storage services on 3 nodes ... DONE (117 secs)
- Setting up IP pool ... DONE (1 secs)
- Setting up file collection ... DONE (5 secs)
- Adding Application Bundles ... DONE (24 secs)
-----------------------------------------------------------------
Cluster with 3 nodes is ready for use
1. ec2-54-215-134-203.us-west-1.compute.amazonaws.com 54.215.134.203 i-0134c468cdede0be2
2. ec2-54-183-234-93.us-west-1.compute.amazonaws.com 54.183.234.93 i-00bb4642b40337ed2
3. ec2-54-183-236-14.us-west-1.compute.amazonaws.com 54.183.236.14 i-0eed2e10c36ba16bf
Robin Cluster Name ..... cluster-Tyaj
Robin Admin Username ... admin
Robin Admin Password ... Robin123
Robin Admin Access ..... https://ec2-54-215-134-203.us-west-1.compute.amazonaws.comAs you can see, the gorobin configures the EC2 instances, creates the robin cluster and configures the cluster with an ip-pool, file-collection and application bundles. On successful completion gorobin provides a URL to access the Robin Cloud Platform cluster along with login credentials.
AWS Regions and Zones
Below is a table of Regions and Zones:
| Region Code | Region Name | Availability Zones |
|---|---|---|
| us-east-1 | N. Virginia | us-east-1a us-east-1b us-east-1c us-east-1d us-east-1e |
| us-east-2 | Ohio | us-east-2a us-east-2b us-east-2c |
| us-west-1 | N. California | us-west-1a us-west-1b us-west-1c |
| us-west-2 | Oregon | us-west-2a us-west-2b us-west-2c |
| ca-central-1 | Canada | ca-central-1a ca-central-1b |
| eu-west-1 | Ireland | eu-west-1a eu-west-1b eu-west-1c |
| eu-west-2 | London | eu-west-2a eu-west-2b |
| eu-central-1 | Frankfurt | eu-central-1a eu-central-1b |
| ap-northeast-1 | Tokyo | ap-northeast-1a ap-northeast-1b ap-northeast-1c |
| ap-northeast-2 | Seoul | ap-northeast-2a ap-northeast-2c |
| ap-southeast-1 | Singapore | ap-southeast-1a ap-southeast-1b |
| ap-southeast-2 | Sydney | ap-southeast-2a ap-southeast-2b ap-southeast-2c |
| ap-south-1 | Mumbai | ap-south-1a ap-south-1b |
| sa-east-1 | Sao Paulo | sa-east-1a sa-east-1b sa-east-1c |
Deploying applications using Robin GUI
In this section, we will show you how to deploy applications using Robin CLI and GUI. We will be using Apache Cassandra through-out this example.
Apache Cassandra is a massively scalable, open source, non-relational database that offers continuous availability, linear scale performance, operational simplicity and easy data distribution across multiple data centers and cloud availability zones. Cassandra was originally developed at Facebook, was open sourced in 2008, and became a top-level Apache project in 2010.
Key Concepts:
- Application Bundle: An Application Bundle is a collection of all artifacts required to deploy and manage an application. It contains one or more application container images, referenced from a manifest file that describes application components, its dependencies, resource requirements, affinity and anti-affinity rules, and custom actions required for management. Bundles are the starting point for creating an application, and as such abstract the underlying infrastructure from the user.
Creating an application bundle is straightforward. You can refer to Section 4 for how to create a bundle.
Application Roles: An application can be made up of multiple components, each deployed in a separate container. These components are described as Roles in the Robin application manifest. For example, a 3-tier application may require a web server, an application server, and a database. Each of these components are modelled as separate roles. Each role is presented separately in Robin GUI, and you can deploy multiple containers for a role, and also provide different inputs if required.
Images for LXC: Both Docker and LXC have container images that are used to create containers. But unlike Docker, LXC does not have a notion of a registry where these images can be stored. Hence, Robin provides an out-of-the-box image registry to store LXC images.
Docker Registry: Robin supports images from both Dockerhub and a Private Registry that may be deployed within the customer datacenter. The Private Registry needs to be deployed and managed by the customer, and, unlike LXC, is not bundled with Robin software.
Robin GUI Overview:
The Robin GUI, a.k.a Robin Lenz, provides visibility to both applications and the underlying infrastructure. When you log into Robin, you will first land on the Dashboard page. The layout of the page is simple, with the collapsible menu bar on the left, and the details on the right.
In this section we will explore the different menu items and pages in detail.
Dashboard
Dashboard is the Primary landing page after logging into Robin. This shows summary information about the applications deployed and the resources consumed, the infrastructure details like cpu, memory, and disk usage and utilization graphs, and alerts & events.
Application Menu
This menu group comprised of Application, Bundles, Templates and Images.
Applications
This view shows all applications deployed on the Robin platform
Bundles
This menu provides List of Out of the box bundles provided by Robin, and any custom bundles you may have created and uploaded.
Templates
This menu lists all the templates saved in the system.
Images
This menu shows the List of LXC container images uploaded to Robin
Infrastructure Menu
This is a menu group comprised of Nodes, Storage, Resource Pools, Network
Nodes
This view shows the list of nodes (compute, storage, or hybrid) that make up the Robin cluster. Here you can drill down to each node and view hardware configuration and infrastructure performance details.
Storage
This view shows the specifications and state of all disks (HDD and SSD) used for Robin storage.
Resource Pools
This view shows a virtual grouping of infrastructure resources used to enable multitenancy.
Network
This view allows you to manage your network settings and create IP pools
Users Menu
This menu is for user and role management. Robin supports two mechanisms for authentication – Embedded Database or LDAP.
Users
This view allows you to add, modify and delete users. It also provides ability to integrate with Directory services AD/LDAP.
Roles
This view shows the list of roles
Tenants
This view allows you to add or remove tenants, manage users within the tenants, set limits for the tenant and set resource pool limits for the tenant.
Copilot Menu
Every long running action in Robin is modeled as Job. This page is used to track progress of various jobs like create, delete, scale out, relocate, snapshot, etc. This view shows alerts, events and jobs.
Settings
This menu will enable administrators to setup Docker private registries.
Configuring Robin cluster (GUI)
In this section we will show you how to configure the robin cluster from the GUI.
Assign resource pools
After installing the robin software on all the nodes, the next step is to assign a resource pool to the nodes. Resource pools provides resource isolation at the application level. It is a way to group certain nodes together and allocate them for some specific applications. Robin by-default creates a resource pool named ‘default’. You can create a resource pool as shown below.
Click on “Resource Pools” as shown below
Then click on the “Add resource pool” at the top right corner of the page as shown below 
and then provide a name and click Add.
Assign Roles
There are Management, Compute and Storage roles. Depending on the resources you can initialize a node to have one or more of these roles. The machine where robin server is installed will be given Management role during the setup. You can provide additional roles during the initialization as shown below.
Click on the nodes from the Infrastructure menu as shown below
On the right side you will see the summary of the Cluster infrastructure as show below. The green indicates an initialized node and the yellow line indicates an uninitialized node. Click on the "Click here to initialize now" as shown by the arrow.
Click on the nodes from the Infrastructure menu as shown below Check the appropriate options for each node. For a converged (hybrid) node, we assign both roles - Compute and Storage, while for a decoupled deployment, compute and storage nodes are assigned their namesake roles respectively. Click initialize.
Robin runs a job in the background to initialize the nodes. You can track the progress of the job by going to "Copilot" as shown below.
Now, click on the jobs tab as shown below. You will see that the initialization job is running. Wait for it to be completed.
Add IP-pool
When creating containers, robin assigns the IP address to the container from the pool of ip addresses defined in the ip-pool. Follow the below steps to set up the ip-pool.
- Click on the Network from the left side navigation menu as shown below
- Now click on the “Create first IP Pool now” as shown below
- Provide name, ip-address range and Netmask and click add. This will add the ip-pool to the robin cluster.
Please note that the subnet for the ip-pool must be present on at least one of the nodes with the compute role.
- Once the ip-pool is successfully added you should see the below details.
Uploading a bundle
As explained in Section 3.1 an Application Bundle is a collection of all artifacts required to deploy and manage an application. In this section we will show you how to add application bundles to robin cluster using both GUI and CLI.
Adding Bundle from CLI
Log into the Robin CLI using your user credentials.
# robin login robin Password: User robin is logged inBefore we upload the bundles, we need to create file collections. Run the below command to create a file collection.
# robin collection create eqx02-poc01-s04.robinsystems.com --size 200G HDD default Submitted job '40'. Use 'robin job wait 40' to track the progressThroughout this section we will be demonstrating capabilities of Robin using Apache Cassandra application. So let us add a Cassandra bundle now.
# robin bundle add cassandra 3.7 docker-cassandra-3.7-CUSTOM.tar.gz File upload: 100% -- (9018120/9018120) Bundle 'cassandra-3.7' was uploaded successfullyRun the below command to verify that the Cassandra bundle is added to the system.
# robin bundle list Bundle Id | Name | Version | Zone Id | File Object Id ----------+-----------+---------+------------+---------------- 1 | cassandra | 3.7 | 1500014636 | 1500358645528
Deploying applications using bundle
Once the bundle is successfully added you should see the bundle in the bundles screen as shown below.
Double clicking on any of the bundles will take you to the “Create Application”. For example, the Cassandra’s “Configure Application” section is shown below.
You can fill up the necessary fields and provision the application. All the fields and information you see on the “Configure Application” section are defined in the bundle. You can see that the Cassandra has two roles seed and member. The Docker logo shows that this application uses Docker images. If the application multiple services defined in the bundle then you will see multiple sections, one each for a service. For example, Hadoop deployments can have different services defined in the bundle; namely Namenode, Datanode, Zookeeper, etc. All of these information is configurable in the application bundle.
Let us now create a Cassandra application. Provide a name for the app, keep the number of seed nodes as 1 and select number of member nodes as 2 as shown in the below screen and click “Provision Application” as shown by the red arrows.
Let us break this screen into different logical sections and a take a closer at each section.
At the top is the Application level input section where you can specify the name of the application, resource pool and ip-pool.
The next section shows whether it is a docker image or a LXC image. In case of a docker image, it shows the image name and tag and the docker registry details.
In the next section, you can specify the resource requirements for the container. You can modify the CPU, Memory and Storage settings here.
The last section as shown below is for the environment variable specific to the application container.
You can also save the entered inputs in a separate file for later use. This is called as an Application Template. This json file, contains all the details required for redeploying the same application configuration from the CLI command ‘robin app create’. The file can be saved to your computer or to any host which has Robin CLI installed.
Depending on the number of containers requested by the application it will take some time for the job to complete. You will see a job progress dialogue as shown below.
Once the job is complete, you will be taken to the next screen where it shows the details about the 3 node Cassandra cluster we just created. You can see the IP address and the host name allocated to the containers.
Now that the application is up and running, let us login into the container and run some Cassandra commands. Click on the Cassandra seed container drop down as shown below and click console. This will launch a console session to the container.
Once you are inside the console, run the following command to see that status of the Cassandra cluster. You can see that the Cassandra cluster is up and running with three nodes. To check status, we use the nodetool utility, which is a native command line interface for managing a Cassandra cluster.
# nodetool status Datacenter: dc1 =============== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.10.1.107 136.72 KiB 256 65.0% 6e25a13d-467c-4abb-afd1-e3e5a54cfdf7 rack1 UN 10.10.1.91 218.12 KiB 256 70.4% c5ec1f8f-7d6f-44f7-95f1-4d66a03c54b9 rack1 UN 10.10.1.112 170.78 KiB 256 64.7% d3f5735d-56b8-4394-9d2b-4b31269737b1 rack1
The output of `nodetool status` provides information about the cluster, such as the state, load, and IDs of every node that make up the cluster. Here we confirm that we indeed see 3 nodes, and all of them are up and healthy.
Next let us load some data using Cassandra-stress as shown below. We are going to write 1000 rows of data to all 3 nodes of the cluster.
cassandra-stress write n=1000 -node 10.10.1.107,10.10.1.91,10.10.1.112 Connected to cluster: cassandra-app, max pending requests per connection 128, max connections per host 8 Datatacenter: dc1; Host: /10.10.1.107; Rack: rack1 Datatacenter: dc1; Host: /10.10.1.91; Rack: rack1 Datatacenter: dc1; Host: /10.10.1.112; Rack: rack1 Created keyspaces. Sleeping 3s for propagation. Sleeping 2s... Warming up WRITE with 750 iterations... Failed to connect over JMX; not collecting these stats Running WRITE with 200 threads for 1000 iteration Failed to connect over JMX; not collecting these stats type total ops, op/s, pk/s, row/s, mean, med, .95, .99, .999, max, time, stderr, errors, gc: #, max ms, sum ms, sdv ms, mb total, 1000, 1412, 1412, 1412, 107.4, 94.5, 231.9, 306.9, 455.4, 455.4, 0.7, 0.00000, 0, 0, 0, 0, 0, 0 Results: Op rate : 1,412 op/s [WRITE: 1,412 op/s] Partition rate : 1,412 pk/s [WRITE: 1,412 pk/s] Row rate : 1,412 row/s [WRITE: 1,412 row/s] Latency mean : 107.4 ms [WRITE: 107.4 ms] Latency median : 94.5 ms [WRITE: 94.5 ms] Latency 95th percentile : 231.9 ms [WRITE: 231.9 ms] Latency 99th percentile : 306.9 ms [WRITE: 306.9 ms] Latency 99.9th percentile : 455.4 ms [WRITE: 455.4 ms] Latency max : 455.4 ms [WRITE: 455.4 ms] Total partitions : 1,000 [WRITE: 1,000] Total errors : 0 [WRITE: 0] Total GC count : 0 Total GC memory : 0.000 KiB Total GC time : 0.0 seconds Avg GC time : NaN ms StdDev GC time : 0.0 ms Total operation time : 00:00:00 ENDRun the below command to see the status.
# nodetool status keyspace1 Datacenter: dc1 =============== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.10.1.107 155.5 KiB 256 32.9% 6e25a13d-467c-4abb-afd1-e3e5a54cfdf7 rack1 UN 10.10.1.91 205.83 KiB 256 32.7% c5ec1f8f-7d6f-44f7-95f1-4d66a03c54b9 rack1 UN 10.10.1.112 194.54 KiB 256 34.4% d3f5735d-56b8-4394-9d2b-4b31269737b1 rack1
Thus, in this section we have successfully created a 3 node, dockerized, Cassandra cluster, and loaded some data, and verified the cluster status using native tools like nodetool.
Scaling a running application
In this section, we will show you how to scale out or add nodes to a running Cassandra cluster with few simple clicks. Cassandra has a scale out architecture, and as such makes addition of nodes fairly easy. But all tooling provided requires the infrastructure to be in place. Since Robin automates both software and infrastructure deployment, the process of scaling out is reduced to a few clicks.
Go to Robin UI, click on Applications menu, and then on the Cassandra application we created in the previous section, as shown with the red arrows in the below image. This will take you to the Cassandra application detail view.
In the Cassandra application details view, scroll down to the “Running Containers” section and click on the “actions” drop down for the ‘member’ role, as shown with the red arrow below. Now click “Scale Out”.
In the next screen, adjust the slider to choose how many new instances needed then click “Scale Out”.
You will see a “Job Progress” window. Once it is complete, you will be taken to the application detail page. You can see the newly added containers there.
Now you can log into the console and run the nodetool status to verify that these newly added containers are part of the Cassandra cluster. You can also see that the load is distributed among all the five nodes now.
# nodetool status Datacenter: dc1 =============== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.10.1.107 243.11 KiB 256 19.5% 6e25a13d-467c-4abb-afd1-e3e5a54cfdf7 rack1 UN 10.10.1.91 302.82 KiB 256 18.0% c5ec1f8f-7d6f-44f7-95f1-4d66a03c54b9 rack1 UN 10.10.1.89 250.27 KiB 256 19.1% 74a42d4a-4433-4f93-89fc-6a655e9b2a6c rack1 UN 10.10.1.99 359.44 KiB 256 21.4% f66c8044-573c-4153-b65c-65dcfa703eec rack1 UN 10.10.1.112 294.78 KiB 256 22.0% d3f5735d-56b8-4394-9d2b-4b31269737b1 rack1
Managing application lifecycle
In this section we will demonstrate, how some of the complex application lifecycle tasks like, taking a snapshot, cloning an existing application and application failovers can be done with few simple clicks in Robin.
Snapshot
Every application provides a proprietary mechanism for taking backups and making clones. While this is sufficient when dealing with components individually, it is a time consuming and painstaking process when dealing with complex, multi-tier application stacks, and data pipelines that combine multiple components. To overcome this challenge, Robin provides a uniform and simplified mechanism for all applications via its ‘Snapshot’ feature.
Robin snapshot is a point in time copy of the entire application topology or data pipeline. This includes the OS, software binaries, configuration, volumes, etc, and thus significantly superior to plain storage snapshots. With Robin snapshots, you effectively put the application topology under version control, and if desired, can capture every change made to it.
Go to Robin UI, click Applications. Locate the Cassandra application and click on the actions dropdown as shown below. Select Snapshot from the Dropdown.
In the next screen provide a snapshot name and click create.
If everything goes fine, you will receive a confirmation message.
Go to Cassandra application detail view, by clicking on the Cassandra application from the Applications view as shown below.
From the application details view, click on ‘MANAGE’. You will see the snapshot details.
Clone
Often times, a developer or a QA engineer would ask for access to production data for testing or debugging purposes. Giving direct access to the production database is undesirable, while traditional data cloning techniques tend to be time consuming and manual. Especially when dealing with large databases, a full clone can resort to heavy storage consumption.
Once again, Robin provides a easy, 1-click, mechanism to clone the entire application stack and data pipelines by leveraging thin cloning techniques. You can create a clone from any of the Snapshots captured for the application. Thin clones are space efficient, as only the delta blocks consume space, time efficient, since they only take a few minutes to create, and fully automated, this includes application deployment and configuration.
In this section, we will show you how to clone application from an existing snapshot. Let us use the snapshot that we took in the previous section and create a clone. Follow the below steps:
- From the application details page, click on the “MANAGE” tab to see list of all snapshots. For the desired snapshot, open the “Actions” dropdown and then click on the “Thin Clone” option as shown by the red arrows.
- You will be presented a screen like the below. Provide a name for your clone and choose a resource pool, an IP-pool, and scroll to the bottom of the page and click "Clone".
- You will see a “Job Progress” window. Once the job is complete, you will be presented with a screen below. You can see the cassandra application we just cloned.
- Click taken to the application details view of the cloned application. Scroll down to the running container section. You will see containers with different host name and ip address as that of the original application. Click on the “Console” menu item, as shown by the red arrow, to get terminal access to the container.
- Once on the console, run the nodetool status to verify if the cloned app is working fine. You can verify that the load distribution is same as the source cluster, and any changes made to the clone, have no impact on the source cluster.
```
# nodetool status
Datacenter: dc1 =============== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.10.1.108 626.56 KiB 256 18.0% c5ec1f8f-7d6f-44f7-95f1-4d66a03c54b9 rack1 UN 10.10.1.113 541.71 KiB 256 19.5% 6e25a13d-467c-4abb-afd1-e3e5a54cfdf7 rack1 UN 10.10.1.102 588.73 KiB 256 21.4% f66c8044-573c-4153-b65c-65dcfa703eec rack1 UN 10.10.1.100 587.97 KiB 256 22.0% d3f5735d-56b8-4394-9d2b-4b31269737b1 rack1 UN 10.10.1.101 601.87 KiB 256 19.1% 74a42d4a-4433-4f93-89fc-6a655e9b2a6c rack1
``` ### Rollback/Restore
In this section, we will show how you can rollback your application to a previous known state using snapshots. Please keep in mind that, once you rollback to a snapshot, any snapshots created before this snapshots will be deleted.
To demonstrate the rollback capability, we will use the same snapshot of the Cassandra application as taken in a prior section. Let us load some more data into the Cassandra cluster, add a new node and create a new snapshot. We will then rollback to our first snapshot.
Follow the steps below.
Go to the Cassandra application detailed page by clicking Applications and the Cassandra application as shown by the red arrows.
From the Application details page, click on Console to launch a terminal session as shown by the red arrows.
Once on the console, run the Cassandra-stress command to load more data. This time, we write 2000 rows to all 5 nodes of the cluster.
# cassandra-stress write n=2000 -node 10.10.1.107,10.10.1.91,10.10.1.89,10.10.1.99,10.10.1.112 Connected to cluster: cassandra-app, max pending requests per connection 128, max connections per host 8 Datatacenter: dc1; Host: /10.10.1.89; Rack: rack1 Datatacenter: dc1; Host: /10.10.1.91; Rack: rack1 Datatacenter: dc1; Host: /10.10.1.107; Rack: rack1 Datatacenter: dc1; Host: /10.10.1.112; Rack: rack1 Datatacenter: dc1; Host: /10.10.1.99; Rack: rack1 Created keyspaces. Sleeping 5s for propagation. Sleeping 2s... Warming up WRITE with 2500 iterations... Failed to connect over JMX; not collecting these stats Running WRITE with 200 threads for 2000 iteration Failed to connect over JMX; not collecting these stats type total ops, op/s, pk/s, row/s, mean, med, .95, .99, .999, max, time, stderr, errors, gc: #, max ms, sum ms, sdv ms, mb total, 1758, 1758, 1758, 1758, 125.5, 115.0, 265.6, 322.1, 367.6, 377.0, 1.0, 0.00000, 0, 0, 0, 0, 0, 0 total, 2000, 2379, 2379, 2379, 102.7, 93.9, 228.0, 260.1, 261.3, 261.3, 1.1, 0.10613, 0, 0, 0, 0, 0, 0 Results: Op rate : 1,815 op/s [WRITE: 1,815 op/s] Partition rate : 1,815 pk/s [WRITE: 1,815 pk/s] Row rate : 1,815 row/s [WRITE: 1,815 row/s] Latency mean : 122.8 ms [WRITE: 122.8 ms] Latency median : 110.3 ms [WRITE: 110.3 ms] Latency 95th percentile : 260.9 ms [WRITE: 260.9 ms] Latency 99th percentile : 317.9 ms [WRITE: 317.9 ms] Latency 99.9th percentile : 367.6 ms [WRITE: 367.6 ms] Latency max : 377.0 ms [WRITE: 377.0 ms] Total partitions : 2,000 [WRITE: 2,000] Total errors : 0 [WRITE: 0] Total GC count : 0 Total GC memory : 0.000 KiB Total GC time : 0.0 seconds Avg GC time : NaN ms StdDev GC time : 0.0 ms Total operation time : 00:00:01 ENDNow run the nodetool status:
# nodetool status keyspace1 Datacenter: dc1 =============== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.10.1.107 433.89 KiB 256 19.5% 6e25a13d-467c-4abb-afd1-e3e5a54cfdf7 rack1 UN 10.10.1.91 541.92 KiB 256 18.0% c5ec1f8f-7d6f-44f7-95f1-4d66a03c54b9 rack1 UN 10.10.1.89 507.65 KiB 256 19.1% 74a42d4a-4433-4f93-89fc-6a655e9b2a6c rack1 UN 10.10.1.99 610.85 KiB 256 21.4% f66c8044-573c-4153-b65c-65dcfa703eec rack1 UN 10.10.1.112 536.76 KiB 256 22.0% d3f5735d-56b8-4394-9d2b-4b31269737b1 rack1Let us take a snapshot of this cluster, as shown in Section 3.3.1 and call it as second_snapshot. Once the snapshot is created you can visit the ‘MANAGE’ section on the application detailed page to see the snapshots.
Now let us go ahead and scale the application by adding two more member nodes to make it a 7 node cluster. Please follow the steps as shown in Section 3.2 . Once the application is scaled, the application detailed view should show the new instances as shown below.
Let us now launch a console session as shown in Step 2 above and run nodetool status to verify if the newly added instances are part of the Cassandra cluster. As you can see the newly added instances are part of the Cassandra cluster and the data load is spread out.
# nodetool status keyspace1 Datacenter: dc1 =============== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.10.1.106 319.51 KiB 256 14.1% 5d656f6f-2e6e-409b-b4ac-241b35a3fad2 rack1 UN 10.10.1.107 612.6 KiB 256 14.1% 6e25a13d-467c-4abb-afd1-e3e5a54cfdf7 rack1 UN 10.10.1.91 721.15 KiB 256 13.4% c5ec1f8f-7d6f-44f7-95f1-4d66a03c54b9 rack1 UN 10.10.1.89 607.64 KiB 256 13.9% 74a42d4a-4433-4f93-89fc-6a655e9b2a6c rack1 UN 10.10.1.99 674.87 KiB 256 15.0% f66c8044-573c-4153-b65c-65dcfa703eec rack1 UN 10.10.1.112 736.59 KiB 256 15.1% d3f5735d-56b8-4394-9d2b-4b31269737b1 rack1 UN 10.10.1.81 297.81 KiB 256 14.4% 1e817886-fb03-4d14-90f1-f1b585490c01 rack1Now, let us rollback the application to the Second-Snapshot. Just to be clear, the Second-snapshot was taken when the cluster had 5 nodes. The cluster currently has 7 nodes. So rolling back to the second snapshot will take the application and its data to that point in time. So after the rollback, our Cassandra cluster should show 5 nodes and not 7 nodes. From the ‘MANAGE’ section on the application detailed page, click on the drop down in front of the Snapshot and click “Restore to this point” as shown by the red arrows.
In the next screen, click ‘Restore’ and wait for the operation to complete.
You should see a confirmation that the app was restored to the snapshot.
You can now click on the ‘INFO’ section of the application detail page and see that the cluster was indeed restored to its earlier point when it had 5 nodes. Click on an instance and launch console as shown below.
Once in the console run the nodetool status. As you can see, the Cassandra application now has been restored to the Snapshot which was taken when the cluster had 5 instances.
``` # nodetool status Datacenter: dc1 =============== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.10.1.107 478.3 KiB 256 19.5% 6e25a13d-467c-4abb-afd1-e3e5a54cfdf7 rack1 UN 10.10.1.91 588.85 KiB 256 18.0% c5ec1f8f-7d6f-44f7-95f1-4d66a03c54b9 rack1 UN 10.10.1.89 706.21 KiB 256 19.1% 74a42d4a-4433-4f93-89fc-6a655e9b2a6c rack1 UN 10.10.1.99 764.32 KiB 256 21.4% f66c8044-573c-4153-b65c-65dcfa703eec rack1 UN 10.10.1.112 582.02 KiB 256 22.0% d3f5735d-56b8-4394-9d2b-4b31269737b1 rack1
```
Thus, rollback of a complete application topology can be achieved with a few clicks. This functionally is extremely powerful when applicationupgrades or patching process goes wrong. With Robin, you can rollback to any snapshot i.e. point-in-time or even effect a factory reset by reverting to the first snapshot after application deploy.
Creating Your Own Bundle
Robin Application Orchestration Framework
Robin System's application orchestration framework is a framework that enables the developers and application administrators to compose, deploy, and manage complex stacks and data pipelines.
This example uses CouchDB; Robin works with other applications in a similar manner.
See https://robinsystems.com/support/docs/#intro for other documentation other applications that can be used with Robin.
For the Getting Started Guides, see (https://robinsystems.com/support/docs/#intro)
Creating a CouchDB Bundle
This section describes how to create a bundle for CouchDB using a Docker image from the official Docker Hub repository.
- Log in to the Robin CLI and create the necessary directory structure for the bundle
# mkdir couchdb
# cd couchdb
# mkdir icons scriptsEach bundle has an icons and scripts directory.
Bundle Applications Icons
Store the Application icons go in the icons directory. Robin GUI uses the icons when displaying bundles. If no icon is provided, Robin displays the first letter of the bundle name.
Bundle Scripts
All the scripts that need to be run during different stages of the application deployment and management are stored in the scripts directory. Scripts are optional.
Create a manifest file.
The manifest file is a YAML file, that contains the complete blueprint of the application. It describes application components, dependencies, resource requirements, scripting hooks, execution order, and others. To create a manifest file for CouchDB. Using any editor in the following lines and save the file as manifest.yaml.
name: couchdb
version: 1.6.1
description: couchdb
icon: couchdb.png
roles: [couchdb]
snapshot: "disabled"
clone: "disabled"
couchdb:
name: couchdb
multinode: false
image:
name: couchdb
version: "1.6.1"
engine: docker
cpu:
reserve: false
cores: 4
compute:
memory: 1024M
storage:
- type: data1
media: hdd
path: /usr/local/var/lib/couchdb
size: 200G
env:
COUCHDB_USER: admin
COUCHDB_PASSWORD: admin
vnodehooks:
postcreate: bash check_status
poststart: bash check_status
The manifest.yaml file is explained line by line:
name: couchdb <-- Name of the bundle
version: 1.6.1 <-- Version of the bundle
description: couchdb <-- Freeform Description
icon: couchdb.png <-- Name of the icon file located in the icons directory
roles: [couchdb] <-- All the roles/services the application requires.
snapshot: "disabled" <-- Does this application require “Snapshot” capabilities?
clone: "disabled" <-- Does this application require “Cloning” capabilities?
couchdb: <-- Section to define the role ‘couchdb’
name: couchdb <-- Name of the role/service
multinode: false <-- Can this role/service have multiple nodes?
image: <-- Image section
name: couchdb <-- Name of the docker or lxc image
version: "1.6.1" <-- Version of the image
engine: docker <-- Is this a docker or lxc engine
cpu: <-- CPU Requirements Details
reserve: false
cores: 4
compute: <-- Compute Requirements
memory: 1024M
storage: <-- Storage Requirements
- type: data1
media: hdd
path: /usr/local/var/lib/couchdb <-- Couchdb requires this path to be
available. Depending on your
application this will change. Also
you may be required to create more
than one volume based on the
application need.
size: 200G
env: <-- Provide any environment variable required during the deployement.
COUCHDB_USER: admin
COUCHDB_PASSWORD: admin
vnodehooks: <-- Define hooks and supporting scripts
postcreate: bash check_status
poststart: bash check_status
The manifest.yaml file in this example was kept simple on purpose. More complex examples are available for clustered applications like Cloudera and Hortonworks.
The next section explains all the attributes supported by the Robin manifest file, while details of application hooks are documented in section 6.
- After you have created that the manifest file is created, tar the entire contents of the directory and create the bundle. Run the following commands In the CouchDB directory.
# ls
icons manifest.yaml scripts
# tar -cvzf /tmp/couchdb.tar.gz \*- Add the bundle to the Robin repository so it can be available in the GUI bundle section.
# robin bundle add couchdb 1.6.1 /tmp/couchdb.tar.gz
File upload: 100% -- (48282|48282)
Bundle 'couchdb-1.6.1' was uploaded successfully- After the bundle is added to the repository, go to the Bundles section in the Robin GUI and provision applications, as described in the previous section.
manifest.yaml
All supported attributes
name: Bundle Name
version: "1.0"
description: Bundle description
website: http://www.mycompany.com
icon: mybundle.png
serialize: true
profile: profile1
snapshot: enabled
clone: enabled
clonemode: unfenced
ha_restarts: 3
ha_relocate: true
roles: [role1, role2]
upgrade_order: [role2, role1]
role1:
name: role1
multinode: true
multinode_label: partition
multinode_fixed: true
multinode_value: 3
multinode_min: 1
multinode_max: 4
candisable: true
description: Role1 description
multi_ips: true
commandline: /bin/do something
entrypoint: custom-entrypoint.sh
scaleout: enabled
addvolume: enabled
scaleup_mem: enabled
scaledown_mem: disabled
scaleup_cpu: enabled
scaledown_cpu: enabled
rolling_upgrade: true
norootfs: false
image:
name: role1-image
version: "1.2-dev"
engine: docker
registry_name: My Docker Hub
upgrade_from: [v1, v2]
init_mode: false
compute:
memory: 1G
cpu:
reserve: false
cores: 4
storage:
- type: data
media: ssd
path: /data
size: 10G
fstype: raw
shared: true
blocksize: 512
nparts: 1
protection: 1
count: 3
mincount: 1
maxcount: 10
affinity: rack
tags:
size: x-large
- type: something
media: ssd
path: /something
service_ports: [60, 443]
env:
BROADCAST_ADDRESS: '{{IP_ADDRESS}}'
MAX_HEAP_SIZE: 512M
ENV_TEXT_EXAMPLE:
type: text
value: "example value"
label: "Text Field"
mandatory: true
editatclone: true
editatscale: true
ENV_PASSWORD_EXAMPLE:
type: password
value: "password123"
label: "Password Field"
ENV_NUMBER_EXAMPLE:
type: number
value: 15
min: 10
max: 20
label: "Number Field"
ENV_BOOLEAN_EXAMPLE:
type: boolean
value: true
label: "Boolean Field"
ENV_FILE_EXAMPLE:
type: filecontent
label: "Contents from a file"
ENV_LIST_EXAMPLE:
type: list
items:
- option1
- option2
- option3
value: option2
label: "List Field"
ENV_TIME_EXAMPLE:
type: date-time
value: 2016-09-21T15:30
label: "Time Field"
vnodehooks:
poststart: "bash do_something.sh ip_address={{IP_ADDRESS}}"
affinityrules: ["same host", "model a or b and not small"]
role2:
name: role2
depends: [role1]
...
apphooks:
poststart: "bash do_something_else.sh"
roleaffinity:
- name: "separate rack"
affinityrules: ["different rack"]
roles: [role1, role2]
affinityrules:
- name: "same host"
constraints:
- type: infrastructure
target: host
- name: "model a or b and not small"
constraints:
- type: tag
target: host
tags:
model: [a, b],
size: ["-small"]
- name: "different rack"
constraints:
- type: infrastructure
target: "-rack"Important
Non-string values that are set to a non-type specific attributes - must have qoutes. Examples: - Environment variable of type:boolean can have value:true, but env var of type:list expects string values so if you want to have 'true'/'false' as the list items, they must be in qoutes: - "true" and - "false". - Bundle version expects a string as well (e.g. '1.2-dev') so pure numeric version 1.0 must be in qoutes, otherwize it would be recognized as a number.
Mandatory attributes
name
name: Bundle NameCurrently not being used. CLI / UI shows the bundle name as it was given during bundle add
version
version: "1.0"Currently not being used. CLI / UI shows the bundle version as it was given during bundle add
icon
icon: myBundle.pngShown in the bundles page in the UI. The image must exist at <bundle_root>/icons/myBundle.png
roles
roles: [role1, role2]An array of role names to be detailed in the manifest.
role1: name
role1:
name: role1Name of the role for display.
role1: image: name
role1:
image:
name: role1-imageName of the image to be used when creating an instance of this role.
For LXC - The name must match the image name that was given when the image file was uploaded to the server.
For Docker - The name must match the image name from dockerhub or private registry (e.g. name:version => cassandra:3.0).
role1: image: version
role1:
image:
version: "1.2-dev"Version of the image to be used when creating an instance of this role.
For LXC - The version must match the image version that was given when the image file was uploaded to the server.
For Docker - The version must match the image version tag from dockerhub or private registry (e.g. name:version => cassandra:3.0).
role1: image: engine
role1:
image:
engine: dockerEngine to be used for instances of this role.
Possible engines: 'docker' or 'lxc'.
role1: scaleout
role1:
scaleout: enabledEnable grow. Adding more containers to a role.
Possible values: 'enabled' or 'disabled'
Default value: 'disabled'
role1: addvolume
role1:
addvolume: enabledEnable adding additional volumes to a role.
Possible values: 'enabled' or 'disabled'
Default value: 'disabled'
role1: scaleup_mem
role1:
scaleup_mem: enabledEnable increasing memory. Adding more memory to containers of a role.
Possible values: 'enabled' or 'disabled'
Default value: 'enabled'
role1: scaledown_mem
role1:
scaledown_mem: disabledEnable decreasing memory. Reducing memory from containers of a role.
Possible values: 'enabled' or 'disabled'
Default value: 'disabled'
role1: scaleup_cpu
role1:
scaleup_cpu: enabledEnable increasing CPUs. Adding more CPUs to containers of a role.
Possible values: 'enabled' or 'disabled'
Default value: 'enabled'
role1: scaledown_cpu
role1:
scaledown_cpu: enabledEnable decreasing CPUs. Reducing CPUs from containers of a role.
Possible values: 'enabled' or 'disabled'
Default value: 'enabled'
Optional attributes
description
description: Bundle descriptionCurrently not being used. The UI will display this text in the creation screen soon.
website
website: http://www.mycompany.comCurrently not being used.
serialize
serialize: trueWhen true, the container provisioning will be sequential based on order in manifest. (e.g. in case of cassandra, we first have to provision seed and then the members 1-by-1)
Default value is false
profile
profile: profile1Profile name will be used in the UI to display app-specific fields and support app-specific behavior (e.g. oracle uses special inputs - SCN / timestamp when performing restore)
snapshot
snapshot: enabled'enabled' - snapshotting will be enabled in the UI.
'disabled' - snapshotting will be disabled with a message in the UI, saying it's been disabled in this build.
'no' - snapshotting will be disabled with a message in the UI, saying that the app does not support snapshotting.
Default value is 'no'
clone
clone: enabled'enabled' - cloning will be enabled in the UI.
'disabled' - cloning will be disabled with a message in the UI, saying it's been disabled in this build.
'no' - cloning will be disabled with a message in the UI, saying that the app does not support cloning.
Default value is 'no'
clonemode
clone: unfencedAn application can be cloned in two modes fenced/unfenced. Fenced clone is a mode where the network properties like ip address, hostname etc are exactly the same as the parent. From the cloned application perspective there is no change needed. Robin acheives this by creating a fence around the cloned application. Robin recommends unfenced clone, and trigger any changes needed in the application as part of the post clone hook. If the manifest file does not have the clonemode defined, during clone operation GUI will provide option to pick the mode.
'fenced' - Clone gets the same network configuration as the parent
'unfenced' - Clone gets new network configuration
Default value is 'fenced'
ha_restarts
ha_restarts: 3Number of times to restart a container before relocating it. The user can override this value in the UI, during creation.
Default value is 3
ha_relocate
ha_relocate: trueShould the container be relocated after it was restarted X (ha_restarts) times. The user can override this value in the UI, during creation.
Default value is true
upgrade_order
upgrade_order: [role1, role2]Only for docker - Specify the order in which roles should get upgraded
role1: multinode
role1:
multinode: trueShould robin create multiple instances of this role.
Default value is false
role1: multinode_label
role1:
multinode_label: partitionIf multinode: true then the UI will give the user a choice to create more than one instance of this role. This attributes defines the app-specific name to be displayed in the UI, next to the instance number input field. (e.g. mongoDB uses 'shard' while cassandra is using 'partition')
Default value is 'partition'
role1: multinode_value
role1:
multinode_value: 3When multinode: true: this attributes defines the initial value for number of instance to create for role1.
Default value is 1
role1: multinode_min
role1:
multinode_value: 2When multinode: true: this attributes defines the minimum value for number of instance to create for role1.
role1: multinode_max
role1:
multinode_value: 4When multinode: true: this attributes defines the maximum value for number of instance to create for role1.
role1: candisable
role1:
candisable: true/falseWhen set to true the UI allows this role to be disabled when creating the final application template (JSON file). By default the value is false (even when it isn't defined in the manifest file). This should only be set to true if the hook scripts for the bundle can handle a missing role in the template file.
role1: multinode_fixed
role1:
multinode_fixed: trueWhen multinode: true: This attributes defines whether the number of instances to create for role1 is editable in the UI.
Default value is false
role1: description
role1:
description: Role1 descriptionCurrently not being used. The UI will display this text in the creation screen soon.
role1: multi_ips
role1:
multi_ips: trueIf multi_ips: true then the UI would let the user pick another IP pool to be used for role1, in addition to the app level IP pool. All containers with role1 would have one IP from each pool. These two IP pools must be on different subnets.
role1: norootfs
role1:
norootfs: falseOnly for Docker - if true - the root_fs type will not be added to storage section. Default false
role1: entrypoint
role1:
entrypoint: custom-entrypoint.shOnly for Docker - if 'entrypoint' is defined - the entrypoint specified will be used instead of the default docker entrypoint. The custom entrypoint script should be present in the scripts folder of the bundle
role1: commandline
role1:
commandline: /bin/do somethingOnly for Docker - if 'commandline' is defined - the UI will display it as a role level input field, and eventually add it to the app template per vnode.
role1: rolling_upgrade
role1:
rolling_upgrade: trueOnly for Docker - Set to true if rolling upgrade is supported for this role
role1: image: upgrade_from
role1:
image:
upgrade_from: [2.*, 3.1]Only for Docker - List of versions which can be upgraded to this version of the image
role1: image: registry_name
role1:
image:
registry_name: My Docker HubWhen engine: docker, the UI will give the user an option to pick a Docker registry if more than one is defined. Use registry_name to define a default registry to use, if it's defined.
role1: image: init_mode
role1:
image:
init_mode: falseBy default containers deployed using Robin infra will have the --init option enabled which will run an init inside the container that forwards signals and reaps processes. If a docker image runs 'init' as an entrypoint, this will result in conflict since there is now processes competing for PID 1. For such images you can set the 'init_mode' to false in the manifest file.
role1: compute: memory
role1:
compute:
memory: 1GDefault memory size limit (in M / G units).
The GUI uses this value to set the default memory limit for role1.
role1: compute: cpu: reserve
role1:
compute:
cpu:
reserve: trueCurrently not being used. Will be used in the future once it's supported in the RCM.
role1: compute: cpu: cores
role1:
compute:
cpu:
cores: 4Default CPU cores limit.
The GUI uses this value to set the default CPUs limit for role1.
role1: storage
role1:
storage:
- type: data
media: ssd
path: /data
size: 10G
fstype: raw
shared: true
blocksize: 512
nparts: 1
protection: 1
count: 3
affinity: rack
tags:
size: x-largeVolume templates array. The '-' char marks the first attribute within each volume object in the storage list. Each type should exist only once.
role1:
storage:
- type: dataVolume type (e.g. data / commitlog / root_fs / etc.).
This field is mandatory within the storage volume object, and must be unique between volumes (one volume template per type).
role1:
storage:
media: ssdMedia to be used for the volume (ssd / hdd) - if available.
Default value is 'hdd'
role1:
storage:
path: /dataDefault path to be used for the volume. See 'count' attribute documentation for additional info.
role1:
- storage:
size: 10GDefault volume size (in G / T units).
Default value is '1G'
role1:
storage:
fstype: rawFile system type (ext4 / ext3 / xfs / btrfs / raw / zfs).
Note: If 'fstype' is 'raw' and 'path' is not defined - the UI would generate default paths: /dev/rda, rdb .. rdz, rdza, rdzb .. rdzz, etc.
Default value is 'ext4'
role1:
storage:
shared: trueWhen shared: true for a volume, than that type of volume template will be shared between all containers in role1. It's a read-only attribute for the UI user and can only be changed in the manifest.
Default value is false
role1:
storage:
blocksize: 512Block size in KB.
Default value is 4 (KB)
role1:
storage:
nparts: 1The number of partitions the block device will support.
Default value is 0
role1:
storage:
protection: 1Volume protection type: 0 = App Provided protection, 1 = Replicated (2 copies), 2 = Replicated (3 copies), 3 = Erasure Coded
Default value is 0
role1:
storage:
count: 3
mincount: 1
maxcount: 12When count: X is defined, the UI would create X volumes of this type, and attached a number to the default path as postfix, from 1 to X (e.g. if path: /data and count: 3, the UI will show 3 volumes of this type, with paths: /data1, /data2, /data3). When mincount: m is defined, UI would enfore that at least m volumes of the said data type are created. When maxcount: M is defined, UI would prevent creation of more than M volumes of the said data type.
Default value is 0
role1:
storage:
count: 3
fixedcount: trueWhen fixedcount: true is defined and set to true, the UI would take into account only count: 3 value; there is no need to have mincount and maxcount values. A dropdown list must be disabled and display count: 3 value.
Default value is 1
role1:
storage:
affinity: rackThe affinity attribute defines where the storage must be allocated from in relation to the instance. In this case, the storage must come from the same rack that the instance is in. Valid values are host and rack.
Default value is None
role1:
storage:
tags:
size: x-largeThe tags attribute defines where the storage must be allocated from. The storage host must match the tags specified. In this case, the storage host must have a size tag of value x-large. Prepend the tag value with a - to indicate a storage host must not have that tag value.
Default value is None
role2: depends
role3:
depends: [role1, role2]If one role depends on another role(s), it must be defined using this attribute so that the UI will enforce it.
role1: service_ports
role1:
service_ports: [80, 443]Port mapping is port based NAT'ing where the traffic to/from the port is NAT'ed out on a different unique port. Service ports is a comma separated list of ports that need to be port mapped per role. Robin virtualization platform maps these ports to unique port on the physical host in the range 20000-30000 if port mapping is enabled during application creation.
role1: env
role1:
env:
BROADCAST_ADDRESS: '{{IP_ADDRESS}}'
MAX_HEAP_SIZE: 512M
ENV_TEXT_EXAMPLE:
type: text
value: "example value"
label: "Text Field"
mandatory: true
editatclone: true
editatscale: true
ENV_PASSWORD_EXAMPLE:
type: password
value: "password123"
label: "Password Field"
ENV_NUMBER_EXAMPLE:
type: number
value: 15
min: 10
max: 20
label: "Number Field"
ENV_BOOLEAN_EXAMPLE:
type: boolean
value: true
label: "Boolean Field"
ENV_FILE_EXAMPLE:
type: filecontent
label: "Contents from a file"
ENV_LIST_EXAMPLE:
type: list
items:
- option1
- option2
- option3
value: option2
label: "List Field"
ENV_TIME_EXAMPLE:
type: date-time
value: 2016-09-21T15:30
label: "Time Field"Environment variables to be used during app creation.
The UI would render these env vars according to the given type (text is default when it's defined as key:value pair).
Type attribute is mandatory if the env var wasn't defined as key:value pair.
The UI would use the label if given to display as a title for the field instead of the env var name.
An environment variable would be treated as optional unless mandatory: true is set for it.
When the order of the env vars is important, they should be defined as an array, by adding '-' before each env var name. example:
role1:
env:
- BROADCAST_ADDRESS: '{{IP_ADDRESS}}'
- MAX_HEAP_SIZE: 512M
- ENV_TEXT_EXAMPLE:
type: text
value: "example value"
label: "Text Field"
mandatory: true
editatclone: true
editatscale: true
- ENV_PASSWORD_EXAMPLE:
type: password
value: "password123"
label: "Password Field"
- ENV_NUMBER_EXAMPLE:
type: number
value: 15
min: 10
max: 20
label: "Number Field"
- ENV_BOOLEAN_EXAMPLE:
type: boolean
value: true
label: "Boolean Field"
- ENV_FILE_EXAMPLE:
type: filecontent
label: "Contents from a file"
- ENV_LIST_EXAMPLE:
type: list
items:
- option1
- option2
- option3
value: option2
label: "List Field"
- ENV_TIME_EXAMPLE:
type: date-time
value: 2016-09-21T15:30
label: "Time Field"Jinja2 support
You can slice and dice the application JSON template to extract exactly what you need for the env variables that are passed to the hook scripts. For example, here's how to get a list of all the storage volumes of type "data" defined for one vnode:
{% for v in vnode['storage'] if 'data' in v['type'] %}
{{v['path']}}
{% if not loop.last %},{% endif %}
{% endfor %}These are on separate lines for readability, but you'd combine them on one line with no spaces between the blocks. The above will give you a comma separated list of all the data directories of a vnode. You'll notice that "vnode" is a variable that's already defined. This will be the JSON of the current vnode that the hook script is running against. You'll also have access to "role" and "app" variables. For app hooks, you'll only have the "app" variable.
Here's another example to get all the ip addresses (comma separated) of all the vnodes across roles "zookeeper" and "namenode":
{% for r in app['roles'] if r['name'] in ['zookeeper', 'namenode'] %}
{% for v in r['vnodes'] %}
{{v['network'][0]['allocated_ip']}}
{% if not loop.last %},{% endif %}
{% endfor %}
{% if not loop.last %},{% endif %}
{% endfor %}There assumes some knowledge of what the template will look like after the allocations are performed and the RCM fills in the additional details (like ip addresses). To see the full template of an already created application on your system, you can use this command:
robin app info <app name> --jsonBuilt-in environment variables
- IP_ADDRESS: IP address of the current container ```yaml Usage: IP_OF_THIS_CONTAINER: "{{IP_ADDRESS}}" IP_OF_FIRST_CONTINER_IN_THIS_ROLE: "{{VNODES[0].IP_ADDRESS}}" IP_OF_FIRST_CONTINER_IN_FIRST_ROLE: "{{ROLES[0].VNODES[0].IP_ADDRESS}}"
Jinja2 equivalent: IP_OF_THIS_CONTAINER: "{{vnode['network'][0]['allocated_ip']}}" IP_OF_FIRST_CONTINER_IN_THIS_ROLE: "{{role['vnodes'][0]['network'][0]['allocated_ip']}}" IP_OF_FIRST_CONTINER_IN_FIRST_ROLE: "{{app['roles'][0]['vnodes'][0]['network'][0]['allocated_ip']}}" ```
- HOSTNAME: Hostname assigned to the current container ```yaml Usage: HOSTNAME_OF_THIS_CONTAINER: "{{HOSTNAME}}" HOSTNAME_OF_FIRST_CONTINER_IN_THIS_ROLE: "{{VNODES[0].HOSTNAME}}" HOSTNAME_OF_FIRST_CONTINER_IN_FIRST_ROLE: "{{ROLES[0].VNODES[0].HOSTNAME}}"
Jinja2 equivalent: HOSTNAME_OF_THIS_CONTAINER: "vnode['hostname']" HOSTNAME_OF_FIRST_CONTINER_IN_THIS_ROLE: "{{role['vnodes'][0]['hostname']}}" HOSTNAME_OF_FIRST_CONTINER_IN_FIRST_ROLE: "{{app['roles'][0]['vnodes'][0]['hostname']}}" * DISKLIST: Comma separated list of block devices attached to current containeryaml Usage: LIST_OF_BLOCKDEVS_ATTACHED_TO_THIS_CONTAINER: "{{DISKLIST}}" * IP_LIST: Comma separated list of IP addresses of all the containers in a role.yaml Usage: LIST_OF_IPS_OF_ALL_CONTAINERS_IN_CURRENT_ROLE: "{{IP_LIST}}" LIST_OF_IPS_OF_ALL_CONTAINERS_IN_FIRST_ROLE: "{{ROLES[0].IP_LIST}}"
Jinja2 equivalent: LIST_OF_IPS_OF_ALL_CONTAINERS_IN_CURRENT_ROLE: "{% for v in role['vnodes'] %}{{v['network'][0]['allocated_ip']}}{% if not loop.last %},{% endif %}{% endfor %}" LIST_OF_IPS_OF_ALL_CONTAINERS_IN_FIRST_ROLE: "{% for v in app['roles'][0]['vnodes'] %}{{v['network'][0]['allocated_ip']}}{% if not loop.last %},{% endif %}{% endfor %}" * APP_NAME: Name of the applicationyaml Usage: CURRENT_APPLICATION_NAME: "{{APP_NAME}}"
Jinja2 equivalent: CURRENT_APPLICATION_NAME: "{{app['name']}}" * ENV: To refer to any of the user defined environmentyaml Usage: MYENV: "test" NEW_MYENV: "{{ENV.MYENV}}" ENV1: "{{ROLES.ROLE1.ENV.ENV1}}"
Jinja2 equivalent: MYENV: "test" NEW_MYENV: "{{vnode['env']['MYENV']}}" ```
apphooks & role1: vnodehooks
role1:
vnodehooks:
poststart: "bash do_something.sh ip_address={{IP_ADDRESS}}"or
role1:
vnodehooks:
poststart: "bash do_something.sh ip_address={{vnode['network'][0]['allocated_ip']}}"or
apphooks:
poststart: "bash do_something_else.sh"Hooks to be used on app life cycle events, in the container (vnode) or app level.
Supported hooks:
precreate
postcreate
prestart
poststart
prestop
poststop
pregrow
postgrow
preclone
postclone
presnapshot
postsnapshot
prerollback
postrollback
predestroy
postdestroy
affinityrules
affinityrules:
- name: "same host"
constraints:
- type: infrastructure
target: host
- name: "model a or b and not small"
constraints:
- type: tag
target: host
tags:
model: [a, b],
size: ["-small"]
- name: "different rack"
constraints:
- type: infrastructure
target: "-rack"Affinity rules dictate how containers and storage should be placed across the physical infrastructure. These rules can inform the RCM that these elements should be located within the same physical boundary, across separate boundaries, and placed according to tags. The rules are made up of a list of constraints. Constraints have the following attributes: * type: Controls what the constraint affects. Can be tag or infrastructure. * target: The object within the type to constrain against. * tags: This is used if the type is tag. The target must have (or not have) the tag values listed here.
The infrastructure type has the following valid targets: datacenter, lab, rack, and host. Containers using this constraint will be grouped by the target. This can be used to place containers within the same host or rack. To ensure containers are in separate hosts or racks, a hyphen can be put at the beginning of the target value: -host, -rack, etc. When this constraint is used at the role level, it applies to all the individual containers.
If the type is tag, the target must be host. This is used to specify the tags the host of the container must use. They can also use the hyphen format to ensure containers don't use certain resources.
There are three separate rules in the above example: * same host - All instances with this constraint must be created on the same host. * model a or b and not small - All instances with this constraint must be created on a host that is of model a or b and must not be of size small. * different rack - All instances with this constraint must be created on separate racks from each other.
role1: affinityrules
role1:
affinityrules: ["same host", "model a or b and not small"]This is how affinity rules are referenced in roles and instances. Here, all instances in role1 must be created on the same host and that host must have model a or b and not be of size small.
roleaffinity
roleaffinity:
- name: "separate rack"
affinityrules: ["different rack"]
roles: [role1, role2] To create affinity between roles, use the roleaffinity attribute. The affinityrules attribute indicates which rule to use. The roles attribute indicates which roles this rule will be applied to. In this example, all instances in role1 must be on a different rack from all instances in role2.
Misc
Service URL support
The 'service_url' attribute in the manifest (under 'appinfo') will enable the user to open the app's native management GUI right from Robin's GUI (the app's menu option would be called 'Manage' in the GUI).
Step 1/2 - Create / Customize your hook script
Example script (written for Wordpress):
import sys
import json
import socket
def get_app_info(app_config):
app_info = {}
for r in app_config.get('roles', []):
for v in r.get('vnodes', []):
if v.get('role') == "wordpress":
if v.get('hostname'):
service_url = None
for port in [80]:
try:
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.settimeout(1)
s.connect((v.get('hostname'), port))
service_url = "http://{}/wp-admin".format(v.get('hostname'))
break
except:
continue
if service_url:
app_info['service_url'] = service_url
return json.dumps(app_info)
if __name__ == '__main__':
json_file = sys.argv[1]
with open(json_file) as f:
app_config = json.load(f)
print(get_app_info(app_config))The script must only print a JSON to the standard output:
Single service URL:
{
"service_url": "http://management-url"
}Multiple service URLs:
{
"service_urls": [
{
"name": "app1",
"url": "http://management-url-1"
},{
"name": "app2",
"url": "http://management-url-2"
}
]
}Put the script file at <bundle_root>/scripts/app_info.py
Step 2/2 - Define the app level hooks in the manifest
Example:
apphooks:
info: "python app_info.py"If the script is working properly and the hook is defined, the app JSON will contain an 'appinfo' object (assuming the REST API was called with the info=true argument), and that object would contain a 'service_url' attribute, to be used by the GUI. # Robin Maintenance
Decommissioning Robin Nodes
Robin allows you to decommission a node from the cluster. Removing a node with Storage role is only allowed if there are no slices or storage allocated from the node with Storage role.
Follow the steps below to remove a node from the cluster:
Check the roles that are currently configured on the host.
# robin host listRemove the roles from the host.
# robin host remove-role <hostname> storage
# robin host remove-role <hostname> computeRemove the host from the Robin cluster.
# robin host remove <hostname>
Configuring Rolling Upgrades
Robin supports rolling upgrades. To perform rolling upgrades on the entire Robin software stack:
- Download the installer to the Master manager node.
- Launch the installer with the “upgrade” argument.
Note: You can pass the username and password from the command line instead of waiting to be prompted
# robin host list
Zone Id | Hostname | Status | State | Pool | Roles | Cores | Memory | HDD (Used/Alloc/Total) | SSD(Used/Alloc/Total) | Instances | Tags
-----------+--------------------------------+--------+-------+---------+-------+-------+-----------------+----------------------------+-----------------------+-----------+------
1494531950 | centos-60-117.robinsystems.com | Ready | READY | None | M* | 0/8 | 1.0 GB/7.63 GB | 0 B/0 B/200.0 GB | 0 B/0 B/0 B | 0 | {}
1494531950 | centos-60-118.robinsystems.com | Ready | READY | default | M,C | 1/8 | 5.82 GB/7.63 GB | 0 B/0 B/200.0 GB | 0 B/0 B/0 B | 1 | {}
1494531950 | centos-60-119.robinsystems.com | Ready | READY | default | M,S | 0/8 | 7.87 GB/7.63 GB | 6.91 GB/133.33 GB/200.0 GB | 0 B/0 B/0 B | 0 | {}
1494531950 | centos-60-120.robinsystems.com | Ready | READY | default | S,C | 1/8 | 5.82 GB/7.63 GB | 1.75 GB/33.33 GB/200.0 GB | 0 B/0 B/0 B | 1 | {}
# ./robin-install_<version>.sh upgrade --username=robin --password=Robin123
===================
= Robin Installer =
===================
Upgrading Robin Server and Agents
Extracting required packages
.
Upgrading Robin software from **<version> to <version>**
Adding SSH keys for upgrade to all nodes
Hostname | Upgrade State | Instances | Applications | Roles | Previous Version | Current Version | Candidate Version
-------------------------------+---------------+-----------+--------------+-------+------------------+-----------------+-------------------
centos-60-117.robinsystems.com | REQUIRED | 0 | | M | None | 3.0.3-20 | 3.0.5-227
centos-60-119.robinsystems.com | REQUIRED | 0 | | M,S | None | 3.0.3-20 | 3.0.5-227
centos-60-118.robinsystems.com | REQUIRED | 1 | cass0 | M,C | None | 3.0.3-20 | 3.0.5-227
centos-60-120.robinsystems.com | REQUIRED | 1 | cass0 | S,C | None | 3.0.3-20 | 3.0.5-227
Upgrade states:
REQUIRED an upgrade is required on this node
PENDING_UPGRADE software has been installed, user initiated upgrade is required
MANAGER_UPGRADED the manager role on this node has been upgraded
user initiated upgrade is required to complete the agent upgrade
COMPLETED upgrade process is complete on this node
System is ready to begin upgrade
Do you wish to proceed? [y/n] y
Proceeding with software installation on all nodes
Building local Robin repository
Set up repository access on remote nodes
Installing software packages on all nodes, please wait...
Software installation on all nodes completed
Hostname | Upgrade State | Instances | Applications | Roles | Previous Version | Current Version | Candidate Version
-------------------------------+-----------------+-----------+--------------+-------+------------------+-----------------+-------------------
centos-60-117.robinsystems.com | PENDING_UPGRADE | 0 | | M | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-119.robinsystems.com | PENDING_UPGRADE | 0 | | M,S | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-118.robinsystems.com | PENDING_UPGRADE | 1 | cass0 | M,C | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-120.robinsystems.com | PENDING_UPGRADE | 1 | cass0 | S,C | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
Upgrade states:
REQUIRED an upgrade is required on this node
PENDING_UPGRADE software has been installed, user initiated upgrade is required
MANAGER_UPGRADED the manager role on this node has been upgraded
user initiated upgrade is required to complete the agent upgrade
COMPLETED upgrade process is complete on this node
Upgrading management layer
Stopping all manager services
Upgrading all management nodes and storage layer, please wait...
Starting watchdog on manager nodes
Restarting all IO managers
Upgrade of all manager nodes and IO managers completed
Hostname | Upgrade State | Instances | Applications | Roles | Previous Version | Current Version | Candidate Version
-------------------------------+------------------+-----------+--------------+-------+------------------+-----------------+-------------------
centos-60-117.robinsystems.com | MANAGER_UPGRADED | 0 | | M | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-119.robinsystems.com | MANAGER_UPGRADED | 0 | | M,S | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-118.robinsystems.com | MANAGER_UPGRADED | 1 | cass0 | M,C | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-120.robinsystems.com | PENDING_UPGRADE | 1 | cass0 | S,C | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
Upgrade states:
REQUIRED an upgrade is required on this node
PENDING_UPGRADE software has been installed, user initiated upgrade is required
MANAGER_UPGRADED the manager role on this node has been upgraded
user initiated upgrade is required to complete the agent upgrade
COMPLETED upgrade process is complete on this node
Robin software upgrade of management layer completed successfully
Please initiate individual node upgrades using 'robin-upgrade' on the command line of the master manager
You may pass the --username=<username>, --password=<password> and --agent-upgrade=<hostname> to robin-upgrade
The status of the current upgrade can be checked using 'robin-upgrade-status'
- Continue to upgrade each remaining nodes until the process is fully completed. Follow the instructions as prompted on the screen.
# robin-upgrade --username=robin --password=Robin123
Hostname | Upgrade State | Instances | Applications | Roles | Previous Version | Current Version | Candidate Version
-------------------------------+------------------+-----------+--------------+-------+------------------+-----------------+-------------------
centos-60-117.robinsystems.com | MANAGER_UPGRADED | 0 | | M | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-118.robinsystems.com | MANAGER_UPGRADED | 1 | cass0 | C,M | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-119.robinsystems.com | MANAGER_UPGRADED | 0 | | M,S | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-120.robinsystems.com | PENDING_UPGRADE | 1 | cass0 | S,C | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
Upgrade states:
REQUIRED an upgrade is required on this node
PENDING_UPGRADE software has been installed, user initiated upgrade is required
MANAGER_UPGRADED the manager role on this node has been upgraded
user initiated upgrade is required to complete the agent upgrade
COMPLETED upgrade process is complete on this node
Management layer upgrade completed, agent upgrade in progress
Enter hostname of node you wish to upgrade next: centos-60-120.robinsystems.com
The following will be affected by downtime
Hostname: centos-60-120.robinsystems.com
Instances:
cass0.member.01 (vnode-95-164.robinsystems.com)
Storage volumes allocated on and served from this node:
cass0
Do you wish to continue? [y/n] y
Stopping all agent services
Starting all agent services
Upgrade of agent node centos-60-120.robinsystems.com completed
Hostname | Upgrade State | Instances | Applications | Roles | Previous Version | Current Version | Candidate Version
-------------------------------+------------------+-----------+--------------+-------+------------------+-----------------+-------------------
centos-60-120.robinsystems.com | COMPLETED | 1 | cass0 | S,C | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-117.robinsystems.com | MANAGER_UPGRADED | 0 | | M | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-118.robinsystems.com | MANAGER_UPGRADED | 1 | cass0 | C,M | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-119.robinsystems.com | MANAGER_UPGRADED | 0 | | M,S | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
Upgrade states:
REQUIRED an upgrade is required on this node
PENDING_UPGRADE software has been installed, user initiated upgrade is required
MANAGER_UPGRADED the manager role on this node has been upgraded
user initiated upgrade is required to complete the agent upgrade
COMPLETED upgrade process is complete on this nodeYou can pass in the hostname as a command-line argument, but this requires user confirmation before beginning.
# robin-upgrade --username=robin --password=Robin123 --agent-upgrade=centos-60-117.robinsystems.com
Hostname | Upgrade State | Instances | Applications | Roles | Previous Version | Current Version | Candidate Version
-------------------------------+------------------+-----------+--------------+-------+------------------+-----------------+-------------------
centos-60-120.robinsystems.com | COMPLETED | 1 | cass0 | S,C | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-117.robinsystems.com | MANAGER_UPGRADED | 0 | | M | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-118.robinsystems.com | MANAGER_UPGRADED | 1 | cass0 | C,M | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-119.robinsystems.com | MANAGER_UPGRADED | 0 | | M,S | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
Upgrade states:
REQUIRED an upgrade is required on this node
PENDING_UPGRADE software has been installed, user initiated upgrade is required
MANAGER_UPGRADED the manager role on this node has been upgraded
user initiated upgrade is required to complete the agent upgrade
COMPLETED upgrade process is complete on this node
Management layer upgrade completed, agent upgrade in progress
The following will be affected by downtime
Hostname: centos-60-117.robinsystems.com
Collections:
file-collection-1 (id: 1)
Do you wish to continue? [y/n] y
Stopping all agent services
Starting all agent services
Upgrade of agent node centos-60-117.robinsystems.com completed
Hostname | Upgrade State | Instances | Applications | Roles | Previous Version | Current Version | Candidate Version
-------------------------------+------------------+-----------+--------------+-------+------------------+-----------------+-------------------
centos-60-120.robinsystems.com | COMPLETED | 1 | cass0 | S,C | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-117.robinsystems.com | COMPLETED | 0 | | M | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-118.robinsystems.com | MANAGER_UPGRADED | 1 | cass0 | C,M | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-119.robinsystems.com | MANAGER_UPGRADED | 0 | | M,S | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
Upgrade states:
REQUIRED an upgrade is required on this node
PENDING_UPGRADE software has been installed, user initiated upgrade is required
MANAGER_UPGRADED the manager role on this node has been upgraded
user initiated upgrade is required to complete the agent upgrade
COMPLETED upgrade process is complete on this node- Use the --script flag to skip any prompts for confirmation.
# robin-upgrade --username=robin --password=Robin123 --agent-upgrade=centos-60-118.robinsystems.com --script
Hostname | Upgrade State | Instances | Applications | Roles | Previous Version | Current Version | Candidate Version
-------------------------------+------------------+-----------+--------------+-------+------------------+-----------------+-------------------
centos-60-120.robinsystems.com | COMPLETED | 1 | cass0 | S,C | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-117.robinsystems.com | COMPLETED | 0 | | M | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-118.robinsystems.com | MANAGER_UPGRADED | 1 | cass0 | C,M | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-119.robinsystems.com | MANAGER_UPGRADED | 0 | | M,S | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
Upgrade states:
REQUIRED an upgrade is required on this node
PENDING_UPGRADE software has been installed, user initiated upgrade is required
MANAGER_UPGRADED the manager role on this node has been upgraded
user initiated upgrade is required to complete the agent upgrade
COMPLETED upgrade process is complete on this node
Management layer upgrade completed, agent upgrade in progress
The following will be affected by downtime
Hostname: centos-60-118.robinsystems.com
Instances:
cass0.seed.01 (vnode-95-148.robinsystems.com)
Running in script mode, proceeding with agent upgrade without confirmation
Stopping all agent services
Starting all agent services
Upgrade of agent node centos-60-118.robinsystems.com completed
Hostname | Upgrade State | Instances | Applications | Roles | Previous Version | Current Version | Candidate Version
-------------------------------+------------------+-----------+--------------+-------+------------------+-----------------+-------------------
centos-60-120.robinsystems.com | COMPLETED | 1 | cass0 | S,C | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-118.robinsystems.com | COMPLETED | 1 | cass0 | C,M | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-117.robinsystems.com | COMPLETED | 0 | | M | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-119.robinsystems.com | MANAGER_UPGRADED | 0 | | M,S | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
Upgrade states:
REQUIRED an upgrade is required on this node
PENDING_UPGRADE software has been installed, user initiated upgrade is required
MANAGER_UPGRADED the manager role on this node has been upgraded
user initiated upgrade is required to complete the agent upgrade
COMPLETED upgrade process is complete on this nodeNote: The upgrade is complete after the final node has been upgraded and all nodes report Upgrade State of COMPLETED.
# robin-upgrade --username=robin --password=Robin123 --agent-upgrade=centos-60-119.robinsystems.com --script
Hostname | Upgrade State | Instances | Applications | Roles | Previous Version | Current Version | Candidate Version
-------------------------------+------------------+-----------+--------------+-------+------------------+-----------------+-------------------
centos-60-118.robinsystems.com | COMPLETED | 1 | cass0 | M,C | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-120.robinsystems.com | COMPLETED | 1 | cass0 | S,C | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-117.robinsystems.com | COMPLETED | 0 | | M | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-119.robinsystems.com | MANAGER_UPGRADED | 0 | | M,S | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
Upgrade states:
REQUIRED an upgrade is required on this node
PENDING_UPGRADE software has been installed, user initiated upgrade is required
MANAGER_UPGRADED the manager role on this node has been upgraded
user initiated upgrade is required to complete the agent upgrade
COMPLETED upgrade process is complete on this node
Management layer upgrade completed, agent upgrade in progress
The following will be affected by downtime
Hostname: centos-60-119.robinsystems.com
Storage volumes allocated on and served from this node:
file-collection-1
cass0
Running in script mode, proceeding with agent upgrade without confirmation
Stopping all agent services
Starting all agent services
Upgrade of agent node centos-60-119.robinsystems.com completed
Hostname | Upgrade State | Instances | Applications | Roles | Previous Version | Current Version | Candidate Version
-------------------------------+---------------+-----------+--------------+-------+------------------+-----------------+-------------------
centos-60-119.robinsystems.com | COMPLETED | 0 | | M,S | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-118.robinsystems.com | COMPLETED | 1 | cass0 | M,C | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-120.robinsystems.com | COMPLETED | 1 | cass0 | S,C | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
centos-60-117.robinsystems.com | COMPLETED | 0 | | M | 3.0.3-20 | 3.0.5-227 | 3.0.5-227
Upgrade states:
REQUIRED an upgrade is required on this node
PENDING_UPGRADE software has been installed, user initiated upgrade is required
MANAGER_UPGRADED the manager role on this node has been upgraded
user initiated upgrade is required to complete the agent upgrade
COMPLETED upgrade process is complete on this node
Removing SSH keys used for upgrade from all nodes
Upgrade process is completeUpgrading Docker Applications
Note; this upgrade is only supported for Docker-based applications.
During the upgrade, the Docker image is replaced. Any configuration changes are handled using pre- or post-upgrade hooks in the bundle.
You can upgrade applications deployed on Robin platform using Robin’s rolling upgrade feature.
Robin’s rolling upgrade provide the following functions:
- Supports rolling upgrade of the applications if the application supports it.
- Provides a facility to do the dry run of the upgrade without any impact on the running application.
- Provides the facility to go back to previous version if update fails or has any issues with new version.
- Provides the facility to track the progress of the upgrade and pause/resume upgrade in case of rolling upgrade.
The following instruction describes the high-level steps to perform the rolling upgrade. This example uses Cassandra; you can adapt it to any other application supported by Robin.
- Add the new bundle which points to the new docker image for the application that you are trying to upgrade.
- The bundle manifest file should have the previous image versions from which the upgrade is supported.
- If the application supports “rolling upgrade”, then the bundle manifest should have the “rolling_upgrade” flag set to true.
- The manifest file should have the upgrade order defined as to which role should be upgraded first.
- After the bundle is added, you can trigger the app upgrade using the GUI or CLI
Using the GUI
To add an updated bundle, as mentioned in step 5, the application page displays a message that upgrades are available for the app.
Click on the Updates Available for the following information: * The version number * The option to select the “Rolling Upgrade” * Run the Test Upgrade, which clones the app and runs the upgrade process on the cloned app version, without impacting the actual production app.
Using the CLI
Use the following command to trigger the application upgrade from the CLI. robin app
# robin app upgrade -h
usage: robin app upgrade [-h] [--bundleid BUNDLEID] [--wait] [--test]
[--rolling]
name
positional arguments:
name Application name
optional arguments:
-h, --help show this help message and exit
--bundleid BUNDLEID Id of bundle to upgrade to.
--wait Wait for command completion
--test Test upgrade
--rolling Rolling upgradeThe following example upgrade the app named “cassandra30” which was based on version 3.0 to version 3.7:
# robin app upgrade --bundleid 3 --wait --rolling cassandra30
Role | Current Version | New Version
-------+-----------------+-------------
member | 3.0 | 3.7
seed | 3.0 | 3.7Adding More Storage to an Existing Container
Robin supports adding more storage to an existing container. Additional volumes can be added using the GUI or CLI. However, the APP needs to add the support for the same.
Before adding additional volumes to an application container, consider the following:
- When you add a new volume to a container, you must provide a mount point.
- You must give a new mount point for the volume you are trying to add.
- Robin will allocate a new volume.
- You must restart the container.
- Post the volume add hook will run.
{{gh (Any application specific logic go here.)
{{gh need an example in the CLI?
Adding Volume from the CLI
To add volumes on Elastic Search using the CLI:
# robin app advol <name> <role> <voltype> <size> <mntpt>For example:
robin app addvol myelasticsearch role user size 10 mntpath /usr/share/elasticsearch/dataNote: Robin supports this feature only for ElasticSearch.
Adding volume from the GUI
To add volume using the GUI: 
Replacing a faulty container
Robin supports replacing or repairing a faulted container. Containers can fault when a drive or host fails from which the container storage was coming from. When that happens, the container does not work. Robin wil mark the volume faulted.
The Repair or Replace feature replaces faulted volumes with new volumes; the container are redeployed according to its affinity rules. This feature only works for the applications that have built-in replication. As a result, when fresh volumes are provisioned for containers, other members of the cluster ensure the data is synchronized and consistent.
Application Bundle Changes
Manifest changes
Role level attributes “can_replace_storage” needs to be set to "true" for this feature to work.
Hooks
Pre- and post-repair hooks run before or after the repair operation. Any application specific logic pertaining to Replace or Repair operations should go here.
GUI Example
Using the GUI, the repair option is displayed in the list of operations for each container.
Here is an example of this new feature from the GUI: 
CLI Example to Repair Instances
Here is the command used in the CLI: ``` robin instance repair es_test.data_node.01
Templates
Template is a way to store the configuration information of an application bundle, and re-use it for deploying similar instances at a later time.
Creating and Saving templates.
Please Navigate to the Bundle page from the Applications menu. Choose the bundle for which you would like to create a template.
Provide a name for the application. Configure the application by filling in all the mandatory fields if any.
Click on the Save Template button and give it a name and save it.
Consuming the saved templates
Navigate to the Bundle page from the Applications menu. Hover over the bundle which you are trying to instantiate. If there is already a template saved the Template link would get highlighted. Clicking on the template link would open a popup window with the template information.
Choosing the appropriate template and clicking on Create App button This would take you to the Application provisioning page.
Illustration
In this section we will show you how to create templates and consume them using MongoDB bundle.
Creating and Saving templates.
- Go to Application > Bundles > MongoDB
- Add application name and edit the configuration as necessary
Click on Save Template as shown below
In the Save Template pop-up Dialogue, fill the Name Field and Description Field and click Save
MyMongo-01 template is created successfully as shown below
Consume the Saved Template
- Go to Applications > Bundles >
- Hover over the Mongodb bundle
Click on the Templates Hyperlink as shown below
Choose the Template of interest from the Drop Down and Click Create App
- This takes back to the Application Provisioning page with pre-populated information from the template. You can now click on the "Provision Application" to provision a new application based on this template.
Robin facilitates creating applications with the help of templates.
Role Based Access Control & Multi Tenancy
Role Based Access Control (RBAC) allows fine-grained access control on a per-user basis. RBAC supports multi-tenancy by isolating users from each other; for example, preventing one user from accessing or deleting another user's resources. In this section we will show you in detail how Robin handles Roles, Tenants and Users.
Roles
Robin's RBAC provides three roles: * Super Admin * Tenant Admin * User
For each type of role, there is a set of capabilities related to 3 main sets: * Application * Infrastructure * User
The User role being least permissive and the Super admin role being the most permissive. The access control system then authorizes all commands performed as a given user by allowing or denying the attempted operation.
The Super Admin has the following capabilities.
These capabilities allow to define actions (i.e. create / manage) a user can do on specific objects or fields (i.e. applications / networking). There are three predefined roles and Robin does not allow the roles to be created, modified or deleted. Roles and their capabilities are located under the Users > Roles menu in the GUI.
Tenants
During the installation Robin creates a default tenant ‘Administrators’. This tenant cannot be deleted. The admin user created during the system install is automatically assigned to that tenant with the ‘superadmin’ role.
Creating new tenants
To create a new tenant, Click on the "Tenants" and then click on the "Add New" as shown in the image below
You will now see the "Add New Tenant" page. Fill up the details as shown below and click "Add" to create a new tenant.
When creating a tenant, all fields but name are optional and can be added after the tenant creation. The Tenant Admin Users can manage the tenants they have been assigned to, their tenant users and their properties. They can also access capabilities of users present in their tenant. Once the tenant is created Members, Resource Pools and IP Pools can be modified. They can all be added to or removed from a specific tenant by going to the following screen.
Setting Limits
Robin allows to set specific resource limits for a tenant and its users:
Within Robin the tenant can have the following limits set: - Maximum number of applications for the tenant - Maximum number of clones for the tenant - Maximum number of snapshots for the tenant
The Users can have the following limits set: - Maximum number of applications per user in the tenant - Maximum number of clones per user in the tenant - Maximum number of snapshots per user in the tenant
The Tenant and user limits can be set from the Robin UI as shown below. 
Setting Resource Pool Limits
In addition to providing limits at the tenant level, Robin also allows limits to be set at the resource pool level for Applications and Tenants.
Within the resource pool the following limits can be set for applications. - Maximum number of cores per application - Maximum memory size per application - Maximum HDD size per application - Maximum SSD size per application
Within the resource pool the following limits can be set for Tenant - Maximum number of cores per tenant - Maximum memory size per tenant - Maximum HDD size per tenant - Maximum SSD size per tenant
The Application and Tenant limits can be set from the Robin UI as shown below. 
Users
A user can be imported from a LDAP/AD server or can be created locally.
Importing users from LDAP/AD Server
Adding LDAP/AD Server to Robin:
Before importing users from the LDAP/AD server, it needs to be regiserted with Robin.
Follow the steps below to add a LDAP/AD server to Robin Service tab, in the GUI, Click on Users --> Directory Service and then click on "Add New" as shown below
In the pop up window enter the following information as shown in the screen below - Server Name - Server Type - OpenLDAP or Active Directory - Hostname - Port - Domain - Username - Password
The username referenced here must be for an existing user in the LDAP/AD domain. This user must be one that can be validated (one where user attributes are returned when querying the LDAP/AD database). The user must also have the ability to read/query the LDAP/AD database (Robin only retrieves information about users and user groups).
Importing Users
Users can be imported from a LDAP/AD server and added to Robin. They can either be imported from a groups list visualization or by searching specific usernames.
Import by group
Import by users
When users are imported, they are assigned a tenant and a role inside that tenant.
Creating Users Locally
To create a user locally, click on users --> add new as shown below 
In the next screen provide the following information - Username - Password - First Name - Last Name - E-mail - Tenant they belong to - Role inside that tenant - The ‘superadmin’ role is available only for the ‘Administrators’ tenant - List of capabilities 
User Capabilities During the user creation process, when a role is selected, a set of capabilities is displayed in accordance with that role. The user can be created with that default set, or capability/ies can be disabled. According to the capabilities a user is assigned, they will be able or not to access screens, objects, actions on objects with in Robin. Capabilities can be modified for a user’s role inside a tenant. From the tenant details screen, users can also be added or removed. A user cannot be removed from their last tenant they have been assigned.
Multi-tenancy
If a user has been assigned to more than one tenant, they can switch their tenant and be logged in with the role that has been chosen for that tenant. This allows to have different roles and capabilities for a single user and therefore to grant them granular access to objects or specific objects sets, according to their tenant. By default, when a user logs in, they will be logged in with the last tenant and role they were previously logged in with.
