Logging in to the dashboard
The primary way to use the NCI cloud is via the web dashboard. To log in, follow these steps:
- Visit https://cloud.nci.org.au
- Select 'NCI' in the domain field
- Enter your NCI username, and your NCI password
- Click on the "Sign In" button.
You will be taken to your default project overview page. If you are a member of multiple cloud projects you can select the project to view from the drop-down box on the top left of the screen.
Setting up a key pair
If you are using Nirin for the first time, ensure at least one key pair exists under your account.
- Navigate to "Key Pairs" under the "Compute" menu on the left of the screen, then either:
- "Import Public Key" if you have an existing key pair you wish you use (make sure that the file you upload is the public key, typically called
something.pub , often
id_rsa.pub in your
- "Create Key Pair" to set up a new key pair.
Setting up a single key pair is a one-time operation. This is the minimum requirement to get started using this guide; more complex workflows or security models may require multiple key pairs.
Creating your first instance
Creating an instance in the dashboard is done using the Launch Instance wizard, which takes you through a number of dialogs collecting information about the instance to be created. Follow the steps below to create a basic instance.
- Log in to the dashboard.
- Click on the Project → Compute → Instances tab and press “Launch Instance” to start a virtual machine. The Launch Instance dialog will appear, open on the Details tab. Enter the instance name and a description, then click on the "Next" button to move to the Source tab.
- In the Source tab select an appropriate image from the list and click on the up arrow to select it, then click "Next" to move to the Flavor tab.
- In the Flavor tab select an appropriate flavour and click on the up arrow to select it, then click "Next" to move to the Networks tab. See Appendix A for more information about flavours.
- In the Networks tab you should find that your project network has been selected by default. Click on the Security Groups tab to proceed.
- In the Security Groups tab you should find that the Default security group is selected by default. Click on the up arrow next to the ssh security group to select it as well, and then click on "Next" to proceed to the Key Pair tab.
- In the Key Pair tab you should find that the key pair you created earlier is selected by default. You can also create or import a key pair at this stage if you have not yet done so.
- At this point the instance is set up fully, and you can click on the "Launch Instance" button to start the instance. Once the instance has been created you will see it in the table in the Project → Compute → Instances tab.
Once the Status becomes "Active" the instance is up and running.
Using Floating IP addresses
The instance created in the previous section has a network connection with a private IP address (10.0.0.18), and can connect to hosts on the Internet, but it is not accessible from the wider Internet. In order to access it externally you need to attach a floating IP to it - this is an externally accessible address that will forward traffic through to the instance on its private address. Follow the steps below to allocate a floating IP and attach it to the instance created previously.
- Log in to the dashboard.
- Click on the Project → Network → Floating IPs tab
- Click on the "Allocate IP to Project" button. This will bring up the floating IP allocation dialog. Select "external" from the pool list and click on the "Allocate IP" button. You can enter a description if you choose, but it is not essential.
- Once the floating IP is allocated you can see it in the list:
- Click on the "Associate" button, and select your instance from the port list. Click the "Associate" button to complete the process.
- The list of floating IPs will now show your instance and its private IP address.
- At this point you can ssh to the floating IP address to access your instance. If you selected an Ubuntu image as the boot source, log in as user "ubuntu", e.g.
When a floating IP address is no longer required, it can be released back to the pool by pressing "Release Floating IP" in the "Actions" column.
Security risk: releasing floating IP addresses
Releasing a floating IP address makes it available for other projects to use, which can in some situations present a security risk. For example, if an external system (such as an old NFS export of gdata filesystems) refers to a public IP address which is released back to the pool and later re-used by another project on the cloud, this could inadvertently give that project access to the external system. To mitigate this risk: before releasing a floating IP address, ensure that any external systems that rely on it are told that the address is no longer valid.
Persistent Volume Storage
Instances in the cloud have a small (10GB) local disk that is intended to hold only the operating system install and its essential files. Additional storage is provided through the use of volume storage. Volumes are effectively an external drive that can be attached to and detached from the instance as required - the volume continues to exist even after the instance is deleted.
To create a volume and attach it to an instance follow these steps:
- Log in to the dashboard.
- Click on the Project → Volumes → Volumes tab
- Click on the "Create Volume" button to bring up the Create Volume dialog, enter a name and set the size. Leave the volume source and type unchanged. Finally, click on the "Create Volume" button to submit the request.
- The volume creation process will take a few seconds. Once it is complete the volume will show in the volume list as Available. Select "Manage Attachments" from the Actions menu on the right, and the Manage Volume Attachments dialog will pop up.
- Select your instance from the list. Leave the device name untouched. Finally, click on the "Attach Volume" button.
- The volume list will show that the volume status is In-use, and that it is attached to your instance.
Log in to your instance and run the
lsblk command to list the block devices. You should see your volume presented on the device listed previously.
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 252:0 0 10G 0 disk
├─vda1 252:1 0 9.9G 0 part /
├─vda14 252:14 0 4M 0 part
└─vda15 252:15 0 106M 0 part /boot/efi
vdb 252:16 0 1G 0 disk
At this point the volume can have a filesystem created on it, and it can be mounted and used.
ubuntu@my-instance:~$ sudo mkfs.ext4 /dev/vdb
mke2fs 1.44.1 (24-Mar-2018)
Creating filesystem with 262144 4k blocks and 65536 inodes
Filesystem UUID: 28813bd6-e50a-40ef-864b-9f4aaa541eac
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
ubuntu@my-instance:~$ sudo mkdir /data
ubuntu@my-instance:~$ sudo mount /dev/vdb /data
ubuntu@my-instance:~$ sudo touch /data/test
ubuntu@my-instance:~$ ls /data/test
NCI offers a range of virtual machine flavours to suit a range of needs. The name of the flavour encodes information about the number of virtual CPUs, and the amount of memory and local disk space that the flavour provides; for example:
- CPUS: 8
- Memory: 16 GB
- Local Disk: 10 GB
The standard set of flavours has 2GB of memory for each virtual CPU, and 10GB of local disk, i.e. 1c2m10d, 2c4m10d, and so on. The largest standard flavour is 8c16m10d, however special purpose flavours can be supported in certain cases.
For more information, see: Nirin Flavors and Charge Rates
Local Disk and Volume Storage: Local disk is only for the operating system install. This storage is not backed up anywhere, and only exists as long as the instance exists. It is strongly recommended that you deploy your instances using an automated process that permits you to rebuild an instance any time it is necessary, and to use persistent storage for anything that cannot be recreated easily.
Persistent storage is provided in the form of volume storage, and is backed onto a redundant and reliable storage backend. In addition, NCI provides tape based storage which is backed up across two remote sites - for more information on this, please contact the NCI Help Desk at firstname.lastname@example.org.
Overview of storage types
|Root disk||/dev/vda, automatically mounted on /||Operating system and applications|
- High IOPS and throughput (Solid State Disks in RAID 0)
- Included in instance snapshots
- Limited size
- No redundancy
- Deleted when virtual machine is deleted
- Not automatically backed up
|Attached volumes aka Block Storage aka Cinder (Backed by Ceph)||/dev/vdb and subsequent, not automatically mounted||Persistent storage of large volumes of data|
- Large size
- High throughput
- Built-in redundancy
- Exists until deleted by owner
- Can be detached from one VM, then re-attached to another.
- Can create point-in-time volume snapshots
- Lower IOPS
- Not automatically backed up
|NCI Global Data Filesystems||NFS exported (see Appendix C for more information)||Use of data sets across different NCI computing platforms, shared access to data from multiple projects, storage of very large data sets|
- Common data storage available to all NCI computing platforms
- Persistent for the life of the project
- Shared access via NFS across multiple instances
- Shared access across multiple projects
- Very large storage capacity
- Easy access to additional data management facilities
- Access via NFS imposes limitations in performance
- Access via NFS requires additional set up and adds complexity
C. Access to the Global File-systems
The NCI Global filesystems can be accessed via NFS exports. Please see NFS Export Policy for global file-systems to Nirin for more details.
D. Additional Information / Policy matters
- Please ensure that the Operating systems and packages are updated regularly to incorporate security and performance improvements.
- NCI uses the IP address range supplied by the Australian National University. These IP addresses are regularly scanned for security vulnerabilities and monitored for suspicious network traffic and behaviour. NCI reserves the right to shut down and lock your virtual machine in the case your virtual machine is not secure, has been compromised and/or is involved in a suspicious activity. NCI staff will inform the virtual machine owner and the project CI with the reasons for shutting down the virtual machine.
- NCI charges for instances in ‘shutdown’ state as shutdown instances consume resources on the hypervisor. If you do not wish to be charged for shutdown instances, please terminate them or shutdown the instance and then shelve and shelve-offload the instance.