Cloud Server

A Cloud Server looks and works like a traditional dedicated server connected to the public Internet or a private network. But it is much more reliable, more flexible, friendlier to the environment because of lower energy consumption and is provided to you at a much lower cost. It is your virtual share of the larger Lunacloud compute & storage infrastructure, with guaranteed resources.

Your Cloud Server will have your choice of a Linux or Windows operating system. You can connect and administer your Cloud Server and configure and install any application you’d like. Some common examples are email servers, web servers and database servers.

• Remote administration or user access via SSH or Terminal Services: like you would normally connect to a dedicated server.
• Web Control Panel: using Lunacloud’s Control Panel with a browser, connected to your account, you can create, delete, start, stop and resize the server resources (RAM, vCPU, Disk).
• RESTful API: the Application Programming Interface is accessible for your applications to control your Cloud Servers, the same way you would via the Web Control Panel, which is very useful for auto-scaling of your applications depending on demand.

vCPU or virtual CPU is a virtual processor, equivalent to a physical CPU on a dedicated server. A Cloud Server can have from 1 to 8 vCPUs

No. Lunacloud’s compute API (the API to control Cloud Servers) is not compatible with Amazon EC2. You can find the API documentation here

A Cloud Server is a set of RAM, vCPU and Disk resources, chosen by you. You can use our proposed bundles (for example, the “Point Five” Cloud server is 0.5 GB RAM, 1 vCPU and 10 GB Disk), but you are free to choose any mix of resources, therefore sizing the Cloud Server to your needs and optimizing the price you pay. The price of a Cloud Server is defined per hour, as per the Cloud Server Pricing page. At the end of each month you will be charged according to the number of hours your server has been running (powered on, at 100% of the rate) or stopped (powered off, at 50% of the rate). We also offer 2 IP’s per region, all the additional IP’s are charged by hour, with a cost of 3,60 €.

You can check pricing anytime at the Cloud Server Pricing page. If your server is active (powered on) you pay the price per hour defined for the mix of resources you are using. If your server is inactive (powered off), you will only pay 50% of the rate per hour. The reason powered off servers are charged is because the resources they’ve been allocated are reserved, i.e., we guarantee the availability of those resources when you power on the server and the data on the disk is also kept. Because the resources are reserved and can’t be used by another customer, they are charged, although at a lower rate because you are not contributing to power consumption. The network traffic actually used by the server is free if it’s inbound traffic (from the Internet to your Cloud Server) and if it is outbound traffic (from your Cloud Server to the Internet) the usage price is defined at the Cloud Server Pricing page. The private traffic (from one Cloud Server to another, on the same private network) is also free. If you don’t want to incur in any charges, you will need to delete your Cloud Server.

The data on the disk of your Cloud Servers is physically on the same datacentre of the compute (RAM and vCPU) resources in a Storage Area Network connected via multiple Gigabit interfaces. This guarantees very good performance of I/O operations, it guarantees that your data is kept safe and not lost if any individual drive fails because of high redundancy levels of the Storage Area Network and it also guarantees virtually unlimited disk space for your Cloud Server, that you can resize anytime.

Our support team is available from Monday 9.00 am to Friday 6.00 pm by phone or ticketing system.

One of the issues that may cause a delay in the authentication process when connecting via SSH to a server is the DNS resolution. On the server side, SSHD typically tries to do a reverse lookup of the IP address of the client, and if for some reason the server is not able to resolve, it causes an unnecessary delay during the authentication process. If you want to avoid this delay, set “UseDNS no” in /etc/ssh/sshd_config and restart the SSHD process. This issue is common in the special case of servers located on a private network and not accessible on the public Internet.