Community
Discussions | Feature Requests | Tips and Tricks
Nimbula Director Concepts
#1March 8, 2011 08:06:00
- Quinton Hoole
- Registered: 2010-08-23
- Posts: 1
Nimbula Director Concepts
Site
A site is a location running Nimbula Director. When installing a site, customers edit a small configuration file; thereafter, the systems self-install Nimbula Director software and self-configure the required services. The site organizes and manages itself with minimal configuration and administration. A site may comprise one or multiple clusters.
site.conf file
The site.conf file is the configuration file that is edited during system installation, containing important information about the site and cluster topology and the root user of the site.
Cluster
A Nimbula Director cluster is a networked collection of computers on which Nimbula Director software runs to provide cloud functionality. A cluster usually runs on a single broadcast domain.
Customers
In Nimbula Director, the customer defines a billable unit. The customer is the context or framework within which system objects such as users, groups and machine images are created and across which default security policies are applied. While it is possible to set up groups within a customer to be very separate in terms of their access to each others resources, the system defaults make it much easier for users within a customer to share resources and harder for users in different customers to do so. Any political units that need real isolation from each other should ideally be separate customers. The customer is the entity using Nimbula Director which will be responsible for any costs incurred associated with system usage.
A customer can be an organization, department within an organization or an individual. At least one customer needs to be created per site to define the entity under whose auspices users interact with the cloud. A customer may have multiple users who can be classified into groups and users and groups must belong to a customer.
Users
A user is an entity within the system that is able to make requests.
Groups
A group is a collection of users and subgroups. When permissions are granted to a group, these permissions are inherited by all members of the group and its subgroups.
Default groups and users
When a customer is added to the system, default groups and users are set up with privileges defined by system policy. For more on permissions, see the sections: Permissions management and Managing users and groups in this guide.
When a multi-user customer is created, four groups are configured by default:
/customer - a base group consisting of all users within that customer. This group has object permissions on all system objects for this customer as well as any public system objects. Any subgroups inherit these object permissions.
/customer/admin - an administrator group with customer administrator user privileges, containing the single customer administrator user /customer/administrator. This group has permissions to perform all actions on all objects for this customer. The password for this user is the password that was specified when the customer was created.
/customer/users – a group which can be used for non administrator users. This group has permissions to launch instances and perform list and get operations on all other system objects but is not able to perform create, update or delete operations.
/customer/public – This group is able to perform any actions permitted by the object owner on any Nimbula Director system objects that have been publicly shared. It also has full access to all public machine images and image lists such as the default Nimbula Director public objects machineimage:/nimbula/public and imagelist:/nimbula/public, which are useful when testing or trying out the system. This group has access to these objects via object permissions.
Machine Image
A machine image provides a hard disk snapshot used to launch a virtual machine instance within the Nimbula Director cloud. The image must be a whole disk image (including a partition table and kernel) stored in a tar archive and compressed with gzip.
Instance
An instance is a virtual machine run by Nimbula Director. Instances have attributes such as allocated RAM, number of CPUs available and network interfaces attached. Instances are created using a launch plan that specifies the desired set of machine images, which image lists they are to be launched from and placement relationships that exist between them.
Netboot
Netbooting allows you to boot and run an installer over the network, independently of data storage devices (like hard disks) or installed operating systems, avoiding a CD based install on each machine. Netbooting uses the PXE protocol and facilitates Nimbula Director's easy installation.
Nimbula Director live CD
A Nimbula Director live CD is a bootable CD which runs a full system independently of the operating system installed on the host machine.
The Nimbula Director live CD contains a machine image of an environment very similar to that which each Nimbula Director site node will run and is used to start the Nimbula Director network installation process. Once the image on the Live CD has booted, DHCP, TFTP and HTTP services start which allow other nodes to netboot using PXE, an automated network installer. The machine used to run the live CD is referred to as the seed node and is typically not a cluster node, but is simply used to "seed" the cluster. The seed node should however have a 64 bit CPU.
A live CD can be obtained from Nimbula or can be created by downloading a Nimbula Director seed ISO from the Nimbula website and burning it to CD. Nimbula Director is built on top of CentOS.
Nimbula Director seed ISO
The Nimbula Director seed ISO is an image of the live CD which must be booted to “seed” the Nimbula Director installation process. Nimbula Director is built on top of CentOS.
Seed node
The seed node is the machine used to run the Nimbula Director live CD. It is typically not a cluster node, but is simply used to "seed" the cluster and then disconnected from the network. The seed node can also run as a VM booted from the Nimbula Director seed ISO. The seed node should however have a 64 bit CPU.
A site is a location running Nimbula Director. When installing a site, customers edit a small configuration file; thereafter, the systems self-install Nimbula Director software and self-configure the required services. The site organizes and manages itself with minimal configuration and administration. A site may comprise one or multiple clusters.
site.conf file
The site.conf file is the configuration file that is edited during system installation, containing important information about the site and cluster topology and the root user of the site.
Cluster
A Nimbula Director cluster is a networked collection of computers on which Nimbula Director software runs to provide cloud functionality. A cluster usually runs on a single broadcast domain.
Customers
In Nimbula Director, the customer defines a billable unit. The customer is the context or framework within which system objects such as users, groups and machine images are created and across which default security policies are applied. While it is possible to set up groups within a customer to be very separate in terms of their access to each others resources, the system defaults make it much easier for users within a customer to share resources and harder for users in different customers to do so. Any political units that need real isolation from each other should ideally be separate customers. The customer is the entity using Nimbula Director which will be responsible for any costs incurred associated with system usage.
A customer can be an organization, department within an organization or an individual. At least one customer needs to be created per site to define the entity under whose auspices users interact with the cloud. A customer may have multiple users who can be classified into groups and users and groups must belong to a customer.
Users
A user is an entity within the system that is able to make requests.
Groups
A group is a collection of users and subgroups. When permissions are granted to a group, these permissions are inherited by all members of the group and its subgroups.
Default groups and users
When a customer is added to the system, default groups and users are set up with privileges defined by system policy. For more on permissions, see the sections: Permissions management and Managing users and groups in this guide.
When a multi-user customer is created, four groups are configured by default:
/customer - a base group consisting of all users within that customer. This group has object permissions on all system objects for this customer as well as any public system objects. Any subgroups inherit these object permissions.
/customer/admin - an administrator group with customer administrator user privileges, containing the single customer administrator user /customer/administrator. This group has permissions to perform all actions on all objects for this customer. The password for this user is the password that was specified when the customer was created.
/customer/users – a group which can be used for non administrator users. This group has permissions to launch instances and perform list and get operations on all other system objects but is not able to perform create, update or delete operations.
/customer/public – This group is able to perform any actions permitted by the object owner on any Nimbula Director system objects that have been publicly shared. It also has full access to all public machine images and image lists such as the default Nimbula Director public objects machineimage:/nimbula/public and imagelist:/nimbula/public, which are useful when testing or trying out the system. This group has access to these objects via object permissions.
Machine Image
A machine image provides a hard disk snapshot used to launch a virtual machine instance within the Nimbula Director cloud. The image must be a whole disk image (including a partition table and kernel) stored in a tar archive and compressed with gzip.
Instance
An instance is a virtual machine run by Nimbula Director. Instances have attributes such as allocated RAM, number of CPUs available and network interfaces attached. Instances are created using a launch plan that specifies the desired set of machine images, which image lists they are to be launched from and placement relationships that exist between them.
Netboot
Netbooting allows you to boot and run an installer over the network, independently of data storage devices (like hard disks) or installed operating systems, avoiding a CD based install on each machine. Netbooting uses the PXE protocol and facilitates Nimbula Director's easy installation.
Nimbula Director live CD
A Nimbula Director live CD is a bootable CD which runs a full system independently of the operating system installed on the host machine.
The Nimbula Director live CD contains a machine image of an environment very similar to that which each Nimbula Director site node will run and is used to start the Nimbula Director network installation process. Once the image on the Live CD has booted, DHCP, TFTP and HTTP services start which allow other nodes to netboot using PXE, an automated network installer. The machine used to run the live CD is referred to as the seed node and is typically not a cluster node, but is simply used to "seed" the cluster. The seed node should however have a 64 bit CPU.
A live CD can be obtained from Nimbula or can be created by downloading a Nimbula Director seed ISO from the Nimbula website and burning it to CD. Nimbula Director is built on top of CentOS.
Nimbula Director seed ISO
The Nimbula Director seed ISO is an image of the live CD which must be booted to “seed” the Nimbula Director installation process. Nimbula Director is built on top of CentOS.
Seed node
The seed node is the machine used to run the Nimbula Director live CD. It is typically not a cluster node, but is simply used to "seed" the cluster and then disconnected from the network. The seed node can also run as a VM booted from the Nimbula Director seed ISO. The seed node should however have a 64 bit CPU.
Edited jacqui (April 19, 2011 02:10:31)