The compute area deals with the resources for your basic VM needs: vCPUs, RAM and root disk size – all three are defined by a concept called “Flavor”. This flavor defines the “size” of your VM, and in our platform there’s a great number of them, plenty to choose from. In a cloud environment you’re no longer able to create VMs with very specific sizing parameters (for whatever reason, like 3 vCPUs and 5.7 GB of RAM) – you have to choose from a list that the service provider gives you. We tried to be creative and came up with a pretty long list that cover most use cases.
Then you need to choose the source for the operating system. We are providing a number of OSes to choose from. If you’re not happy with the selection – feel free to ask for additions or upload your own image. Bear in mind, that you’re responsible for the licensing and intellectual property violations if you’re using your own images. One very important aspect about the images – we neither know what the root or Administrator password is, nor we can somehow hack it for you, sorry. The Linux-based images can be initially accessed using a key-based SSH authentication only, Windows-based instances ask the user to set the Administrator password upon the first boot – make sure you check the console tab of your VM in the self-service portal. Once you have your Linux VM running – you can then set the root password you want, snapshot the VM and then use that snapshot to create additional VMs with a pre-defined root password that you know, but we endorse and promote a more secure SSH key-based authentication as a default and initial option.
The root disk is an important aspect – this is the location for the operating system and the applications that you might want to install. In a Windows world it’s disk C: 🙂 This kind of setup might seem to be restrictive but only at the first glance. The idea behind this root disk concept is that the application or whatever other data should resize in it’s own dedicated space and that space is provided by storage volumes (or LUNs, in the old school speech).
In our platform we have three tiers of storage to choose from: Tier 1 – SSD storage, Tier 2 – SAS storage, Tier 3 – NL-SAS storage. It’s entirely up to you to decide what kind of storage you need for your business. Can you also add volumes from different storage tiers to same VM and aggregate that storage using LVM in Linux or Storage spaces in Windows. Windows can also leverage Dynamic disks but I’d strongly recommend Storage spaces as it’s a native Windows Server component since 2012 and much more flexible.
Once you create a storage volume you can then attach it to a VM. At the moment you can attach it to a single VM only – once we launch a new Telia Cloud Platform version (v2) you’ll be able to attach it to multiple VMs but not at the moment. The nice thing with volumes is that you can create snapshots of them (think – instant backup) and even create new volumes from these snapshots if needed.
When creating a new volume from snapshot you have to use the same tier of storage (which may seem restrictive but that’s the nature of snapshots). However, you can then safely change the tier of storage by retyping the newly created volume from snapshot to whatever storage tier you want – select the action “Change volume type”, then set the name, target storage tier and make sure you select migration policy “On demand” because the policy “Never” is, well, never…
You can also extend volumes to make them bigger. Naturally, you can’t do this though with a volume that’s in use and attached to a VM because it’s risky to do so. So if you need to extend the volume to make it bigger – make sure you safely unmount it in the OS and detach it from the VM before attempting to extend it. Or, alternatively, you can use snapshots and creating new volume from snapshots to make this happen and then sync the new volume with the original volume in the OS whilst both volumes are attached, and umount and detach the original volume when no longer needed. This is just one example, you can be much more creative than I am 🙂
Network is absolutely fundamental and planning your network properly is a must. We don’t know your business that well as you do, hence we don’t pre-provision any private networks for you. The only pre-provisioned network that you’ll find is “Public-Internet” which is, well, The Internet. You get your Internet accessible IP addresses from that network.
While you can, of source, plug your VM directly to the Public-Internet network (think – WAN), it may not be the wisest thing to do, unless you really know what you’re doing. Some old school people get confused about virtual or floating IP addresses because they like to see the IP address in the NIC configuration. With virtual/floating IPs it’s different – you see your private network IP address on the NIC and assign a virtual/floating IP address on the cloud platform level. Simply put, the floating IP is a 1:1 BI-NAT operating on the virtual router level and that’s the default operating model in any cloud environment. To use this kind of model you need to do two things – 1) create a new project internal network (think – LAN) with a subnet in it; 2) create a virtual router with a gateway set to Public-Internet and add additional interface to your project internal network. By doing this you’ll be able to launch your VMs in your private project network and provide them with the ability to SNAT to the Internet (get updates, download scripts and what not) and assign floating IP addresses only to those VMs that really need to be reached directly from the Internet by DNAT. The nice thing about floating IPs is that they can be viewed as IP address stickers – such “sticker” can move around servers very easily without any need to reconfigure your NICs on the VMs.
All in all, I recommend setting up at least one project internal network with a virtual router connecting it to the Internet and use floating IP addresses for the use cases requiring access from the Internet to the VM provided resources. Oh, and don’t forget about the Security groups – they are your endpoint firewalls, and you can have multiple security groups, each tailored for every specific VM role, like web servers, DB servers, middleware servers, etc. The rule set in the default security group permits only outgoing requests (egress rules). If you need remote access, like SSH, make sure you add rules permitting incoming requests (ingress rules) and don’t leave that default CIDR 0.0.0.0/0 – every address on the Internet matches this rule, try to be more specific where possible and reasonable.
There’s also another option for your networking needs – virtual router, firewall, load balancer and VPN appliance. We’re happy to provide OPNsense virtual appliances, more on this subject in the future posts.