Type | Information |
---|---|
Service Provider | University Ss Cyril and Methodius, Faculty of computer science and engineering |
Status | Final |
Version and date | 1.0, 11.01.2021 |
Version | Date | Comment | Author |
---|---|---|---|
0.1 | 30/05/2020 | Initial User Guide Template | Mihajlo Savic |
0.2 | 12/06/2020 | Draft version of the User Guide Template | Mihajlo Savic |
0.3 | 18/06/2020 | Minor edits to the front page | Mihajlo Savic |
0.4 | 22/11/2020 | Adding additional subsections related to resource provisioning, networking, and common troubleshooting steps | Vojdan Kjorveziroski |
1.0 | 11/01/2021 | Final revision, added introduction and scope | Anastas Mishev |
The FINKI Cloud is a cloud service provided by the University Ss. Cyril and Methodius, Faculty of Computer science and engineering in Skopje.
The infrastructure is based on OpenStack and is hosted on 15 Huawei servers, each with 128GB RAM and 20 HT CPU cores, totalling in 300 vCPU cores and 37TB SSD and 32 TB SAS storage. The system is in production from 2017 as a National cloud system. The connectivity to the Internet is 1Gbit through MARNET provided link to GEANT.
Currently the system hosts templates for all popular Linux distributions, and Windows variations.
The target user communities for this service are researchers and research groups form all scientific areas, with special focus on the long tail of science, due to the modest capacity of the services. It is meant to provide those researchers and groups easy access to computing environment in the cloud, with images for the operating systems and solutions most frequently used in scientific cloud environments.
This user guide is organized in multiple sections, each explaining different aspects of the cloud platform, giving the end-users advice on recommended actions, and troubleshooting steps that can be performed. The rest of the document is organized as follows:
In section two a general overview of the requirements for accessing the service and the login procedure is given, focusing on the steps that need to be taken by a federated user to use it for the first time.
Section three documents the most common workloads that a user might need to perform in order to get a fully functioning virtual machine with both inbound and outbound network access, along with steps required for attaching multiple persistent storage disks, assigning flexible floating IP addresses, and tips for securing inbound and outbound access to the instances themselves. The section is concluded with topics focused on working with user identity, user management and public key management.
Section four deals with the most common troubleshooting scenarios that a user might perform by themselves and gives additional instructions on contacting the Helpdesk, as well as checking the operational status of the service at any point in time.
To access the Web based graphical user interface of this service, the user has to use a modern and standards compliant Web browser with enabled support for JavaScript, such as the latest supported versions of Google Chrome, Mozilla Firefox, Apple Safari or Microsoft Edge.
To access the REST API endpoints of this service, the user has to be able to execute standard HTTP methods, including HTTPS (TLS 1.2). Additionally, open-source OpenStack API libraries are available for the majority of operating systems and programming languages, further easing this interaction.
Users must be verified by one of the partners in the project and granted access by the relevant Work Package leader or Task Group leader before accessing the service.
The authentication procedure can be performed through the Web based UI (Horizon) or through the command line interface, utilizing the REST API of the service. The Web based interface provides support both for a username-password pair (Figure 1) and for the Project’s AAI - NI4OS AAI (Figure 2).
WARNING: If the user were previously issued a username and password pair, this would preclude usage of the same username when logging in via the Project AAI service. The user would have to choose another username and would have to maintain two separate identities within the scope of the service.
This section explains the most common actions performed by end-users and provides suggestions on the recommended configuration options to be used during initial resource deployment
Upon successful login using one of the login methods explained in section 2, the user is presented with an overview dashboard showing the most important data including the usage of the allocated compute, storage, and networking resources (Figure 3). The user has the option to access the active instances directly from the list available at the bottom of the view or by selecting the menu option Instances within the Compute group on the left side of the screen (Figure 4).
The creation of a new virtual machine instance is one of the most common workflows that can be undertaken by an authorized user. The process consists of multiple steps that must be completed before the instance is assigned to a compute node and provisioned.
The first step towards launching a new virtual machine instance is going to the instances section by using the navigation menu on the left-hand side and choosing Compute -> Instances. There, in the top right corner a Launch Instance button is visible (Figure 4) which opens the virtual machine creation wizard (Figure 5).
This wizard consists of multiple steps, outlined on the left-hand side of the pop-up window, each gathering different information for the instance to be created.
Notice: When creating multiple instances at once, the system will automatically append sequential numbers to the end of your specified name in Instance Name.
Notice: Any additional volumes besides the main one that houses the operating system will appear as raw block devices in the operating system and will have to be manually formatted and mounted by the end-user.
external-3000
, as shown in figure 8.Notice: It is best to configure any additional network interfaces once the virtual machine has been created. In this way you will have complete control of the interface order and intended purpose from within the operating system.
Notice: Make sure to select a public key even when deploying a Microsoft Windows instance, since the initial temporary password is derived from it.
The virtual machine will go through multiple phases, such as Allocating Block Storage, Spawning, etc… Please patiently wait until it reaches the Active state as seen in figure 9. Once in the Active state you can use the default remote access protocol (SSH for GNU/Linux instances, Remote Desktop for Microsoft Windows instances) for the selected operating system for connecting to the virtual machine by using its allocated IP address. If a public key has been selected during the deployment process, then no password will be required for login. The username used will depend on the operating system that has been requested, and it is usually the name of the distribution (ubuntu
for Ubuntu instances, debian
for Debian instances, centos
for CentOS instances…).
Additional configuration can be performed to any virtual machine after it has been deployed. To do so, navigate to the Compute -> Instances section of the Web interface, where you are presented with a list of all the deployed instances in your current project, as seen in figure 9. Upon selecting a desired instance from this list, the user is presented with a detailed view of the instance, including the option to perform one of the available actions, from managing the network settings and attached interfaces, working with volumes and snapshots, to controlling the execution of the instance including pausing, suspending or shutting down the instance (Figure 10). Many of the functions are also available through the tabbed User Interface with Overview being the tab selected by default, while Interfaces, Log, Console and Action Log provide further information and management options to the user (Figure 11, Figure 12).
All volumes defined inside the given project can be managed from the Volumes -> Volumes section and the other sections on the same level (Snapshots, Groups, Group Snapshots).
A new volume attachable to any existing virtual machine can be created by selecting the Create Volume button in the top right-hand side of the Volumes -> Volumes section (Figure 13). Once clicked, a popup window appears where the user can select the desired configuration for the new volume, as shown in figure 14.
Start by selecting the desired name for the new volume through which it will be identified. Choose No source, empty volume in the Volume Source dropdown menu. The Type of the volume depends on whether you require high disk performance (RBDFAST - storage backed by SSD disks) or normal performance (RBD - storage backed by mechanical disks configured in RAID10). Finally, select the desired size of the new disk in gigabytes, taking into account your project’s storage quota.
Once the volume has been created, it can be attached to any running instance while running. For more information please see section 3.1.2, Interacting with an existing virtual machine instance.
Any volume can be snapshotted and later this snapshot can be used as a source volume for a new virtual machine instance.
The two main ways in which a snapshot can be created are:
All the created snapshots for a given volume are listed in the Snapshots tab of the Volumes section, as presented in figure 16. The details about a particular snapshot can be seen by clicking on its name, opening an interface similar to the one presented in figure 17.
After a snapshot has been created a new instance can be created from it by selecting Instance Snapshot as the boot source during the instance creation procedure, more details are available in section 3.1.1, Creating a new virtual machine instance.
Networking is an essential part of the virtual machine instances configuration. In this section, a brief overview of this topic is given, along with short guides on how to assign a public IP address to a given instance, utilize private networks, and create floating IPs that can be freely moved between virtual machines.
Depending on how the virtual machine will be used, users have the option to allocate and associate a public IP address with it. To do so, as stated in section 3.1.1 - Creating a new virtual machine instance, the global network that is accessible to all projects, external-3000
, must be selected. In cases when no public access is needed, or users have the opportunity to use a jump or bastion host to access their resources, internal per-project networks can be used, explained in more details below.
Notice: Since IPv4 addresses are a scarce resource, please only utilize the external-3000 network only if absolutely necessary, as to provide fair access for other users as well. A recommended (and more secure) way in which you can access your instances is by utilizing a jump or bastion host that will be placed both in the public network and in any internal networks created within the project.
Internal networks allow you to completely isolate your virtual machines from other projects and provide secure means of intra-project VM communication. In order to create a new internal network, the following steps must be executed:
In the Network tab of the new network wizard, specify only the name for the new network and leave the other settings to their default values:
In the Subnet tab of the new network wizard, enter the name for the first subnet created inside this network, along with the address range that will be dedicated to it using a CIDR prefix notation in the Network Address field (e.g. 192.16.1.0/24). If this will solely be an internal, air-gapped network, with no external Internet access, select Disable gateway, otherwise, if you want to configure NAT for external Internet access for resources in this network, leave the default values (Figure 20):
Once all of the required fields have been configured, the network can be created using the blue Create button in the right-hand side corner.
If a NAT configuration is required, where instances added to the newly created network would also have public outbound access, then additional configuration is required - a router in the Project -> Network -> Routers section will need to be configured. The required steps for this are:
external-3000
option, keeping the option Enable SNAT option checked. This will allocate one public IP address from the external-3000
network as a gateway address.Once all of the above steps have been completed, any instance that has been added to the newly created network will have unrestricted outbound Internet access.
Notice: By using a private network with a public gateway you are conserving public IPv4 addresses and further increase the security of your virtual machines, since no direct external access would be possible.
Floating IPs are IP addresses that are not tied to any particular virtual machine and can be reassigned from one instance to another, using just a few clicks. This allows you to keep your known public IP addresses, even when the underlying virtual machines will be deleted.
Floating IPs can be provisioned from the Project -> Network -> Floating IPs page accessible through the left-hand side navigation menu. The steps that need to be taken are the following:
external-3000
in the dropdown field titled Pool.Notice: Floating IPs are transparent to the end-instance to which they are attached, meaning that when listing the network interfaces from within it, the floating IP address will not be shown.
The purpose of a security group is to regulate inbound and outbound network traffic to a virtual machine. Every project has a rather restrictive security group defined by default and in many cases changes to the default security group or a creation of a completely new security group might be required.
Security groups can be defined from the Project -> Network -> Security Groups menu. To do so, the following steps need to be followed:
Notice: Please exercise caution when creating new inbound security rules and use the filtering feature to only allow traffic to the chosen port from a well-defined range of IP addresses, whenever possible.
This part of the guide focuses on how end-users can interact with other members of their project and alter their public SSH keys associated with their profile.
A single project in FINKI Cloud can be accessed by multiple members, allowing collaboration and sharing of the resource quota assigned to that particular project.
To view the list of users assigned to a given project, users can navigate to Users page accessible through the navigation menu on the left-hand side, Identity -> Users.
As discussed previously in section 3.1.1 assigning a valid SSH public key is an essential step during the deployment of a virtual machine instance. Users can preview all their associated SSH public keys and even create new SSH key pairs by accessing the Project -> Compute -> Key Pairs page through the left-hand side navigation menu. There, either an existing public key can be imported, by clicking on the Import Public Key button, or a complete new private key pair can be generated by the system itself, automatically associating the public key part with the users profile and providing a download link for the private key. A new private key pair can be generated by clicking on the Create Key Pair button.
In case of issues with the FINKI cloud service itself, or with some of the resources provisioned through it, users should first check the status of the service through the NI4OS Europe monitoring dashboard, available at: https://argo.ni4os.eu/.
Should there be no known issues with the status of the service, users can attempt to troubleshoot some common problems themselves, by following the steps explained in the subsections below.
If no solution can be found and the problem persists, end-users can submit a help request through the helpdesk, available at: https://helpdesk.ni4os.eu/
In case a deployment of a new virtual machine fails, its status will be changed to Failed. This usually indicates a problem with the underlying infrastructure, but end-users can reattempt the provisioning of the virtual machine by deleting the failed instance and creating a new one.
If after a successful virtual machine deployment there is a problem accessing it remotely or some ports that are supposed to be open are not reachable, then it is most likely a misconfiguration of the security rules associated to the security group assigned to the given virtual machine. Please refer to section 3.3.4 for more details on how to configure inbound and outbound network policies.
After a virtual machine deployment, remote access to it might not be possible. To troubleshoot the issue, please verify the following:
telnet
or netcat
. If the port is not open, refer to the troubleshooting section for connectivity problems, available above.The service will be fully integrated with the NI4OS-Europe and EOSC infrastructure, providing AAI, monitoring, accounting and helpdesk support. More about the service can be found at the service catalog available at: https://catalogue.ni4os.eu/.