- What is CREODIAS?
- Computing & Cloud
- Data & Processing
- Pricing Plans
- Examples of usage
- Example of tool usage
- Processing EO Data and Serving www services
- Processing and Storing EO
- Embedding OGC WMS Services into Your website
- GPU Use Case
- Using the EO Browser
- EO Data Finder API Manual
- Use of SNAP and QGIS on a CREODIAS Virtual Machine
- Use of WMS Configurator
- DNS as a Service - user documentation
- Use of Sinergise Sentinel Hub on the CREODIAS EO Data Hub
- Load Balancer as a Service
- Jupyter Hub
- Use of CREODIAS Finder for ordering data
- ESRI ArcGIS on CREODIAS
- Use of CEMS data through CREODIAS
- Searching, processing and analysis of Sentinel-5P data on CREODIAS
- ASAR data available on CREODIAS
- Public Reporting Dashboards
- Sentinel Hub Documentation
- Integration Guides
- OGC API
- Custom Processing Scripts
- Legal Matters
- Partner Services
- About Us
Computing & Cloud
Virtual Machines (VMs) are fully functional computational instances. They operate as if they were real physical entities with all the elements of a physical server. A user obtains his VM with full root access. He can fully manage it and install any software he has and needs.
In the EO Cloud Users can use Virtual Machines (VMs) by defining their different parameters and characteristics, including machine type (physical or virtual), RAM, CPU (vCores), Storage quantity and type, Operating System, middleware components, Virtual Networks connected to the machine.
Users determine the characteristics of a newly provisioned VM by selecting its Flavor and base image. Currently available flavours are presented in the following table:
|Available VMs||#vCores||RAM (GB)||SSD Network Storage (GB)|
|ArcGIS.ds.large||40 (20 cores)||112||2 x 1000 (local NVMe)|
* All Software ready Cloud Servers are available only with Windows Server Standard in bundle with preconfgured Esri ArcGIS Pro Desktop.
The list of currently available operating system images is presented below:
- CentOS 6, 7
- Ubuntu 14.04 LTS, 16.04 LTS, 18.04 LTS
- Windows 2016 mini / full
- RHEL 6,7 mini / full
- SLES 12 mini / full
- OSGeo 11.0
- App Catalog Image
All the VMs come fully configured (based on the image selected) and ready-for-use, with an administrative User account, network access, preconfigured toolboxes and software components. Volume Storage may be attached to running VM-s to extend the storage space available. VMs can be started, stopped, rebooted, paused, suspended and snapshotted. Live backup functionality is also available, including server quiescing. VMs may also be attached to Virtual Networks. Virtual Networks may be system-defined or User-defined.
System defined networks include:
- Internet network used to access the global internet
- the EO Storage network available in Projects/Environments that are allowed access the EO Storage
Users may utilize VM-s and other cloud Resources using the EO Cloud Dashboard, the REST API, a command line client or the Openstack Orchestration scripts (Heat). VMs can be connected to the network using virtual interfaces.
The VMs can be billed in monthly or longer quanta (Fixed Term Mode) or can be billed per hours of usage (Per Usage Mode). Users may also temporarily shelve their VMs based on persistent storage, paying only for the persistent storage space they occupy.
Figure 3 - Cloud Dashboard - Instances
The instances as seen in the Cloud Dashboard are presented in a picture above.
Dedicated Server Virtual Machine
DSs are special VMs. Each DS is a virtual machine that fills the full computing machine (hypervisor server). There are no other VMs in this server. So a User of an DS has a full physical server for his own use. Additionally SVMs are equipped with very efficient SSD disks installed in pass through mode. This way full capacity and speed of those disks can be utilized. DSs are a perfect solution for everybody who wants to have efficiency and independence of Baremetal Servers but simultaneously wants to utilize all the elements of the OpenStack cloud platform. For details – see DS flavor list below.
Figure 4 - DS Flavours
|Available DSs||#vCores||RAM (GB)||SSD NVMe Local Storage (GB)|
|ds.medium||40 (20 cores)||48||2 x 500|
|ds.large||40 (20 cores)||112||2x 1000|
|ds.2xlarge||40 (20 cores)||368||2x 1920|
|ds.3xlarge||48 (24 cores)||496||2x 1920|
|ds.large.gpu**||40 (20 cores)||112||2x 1000|
* If the above configurations do not fit your project, please contact our sales team (email@example.com) to design a custom solution.
** ds.large.gpu is equipped with GeForce GTX 2080 Ti (4352 CUDA Cores, 11GB GDDR6)
DS can be provisioned in exactly the same way as standard VMs. Users may utilize DS-s and other cloud Resources using the CREODIAS Dashboard, the REST API, a command line client or the Openstack Orchestration scripts (Heat). DSs can be connected to the network using virtual interfaces.
The DSs are billed in exactly the same way as standard VMs.
Containers are isolated, portable environments where one can run applications along with the libraries and dependencies they need. Containers are not VMs. In some ways they are similar, but there are even more ways that they are different. Like VMs Containers share system resources for access to compute, networking and storage. They are different because all containers on the same host share the same Operating System kernel and keep applications, runtimes and various other services separated from each other using kernel features known as namespaces and groups. Docker added the concept of a container image which allows containers to be used on any host with a modern Linux Kernel. The Container image allows for much more rapid deployment of applications than if they were packaged in a VM image.
Our system provides two types of Containers – Docker Swarm and Kubernetes.
Containers are provisioned with the use of Magnum and/or Murano modules. During the provisioning a so called Bay is created located on one or several VMs. The parameters of these VMs are either set automatically or by the User. There is then no limit on the number of Containers in such a Bay.
The Containers billing depends on the billing of the underlying VMs. The VMs creating a Bay are billed as described in the section on VMs.