Contemporary tendency of use the cloud architectures is quite common. Many tests show that the price for using a commercial cloud is feasible for most of applications including High Energy Physics. At the same time, many users are still using the large data centers (DC). The using just one data center (DC) is not completely sufficient in several aspects. First is lack of isolation, and second is lack of elasticity. Lack of isolation means situation when many users share one DC and violate SLA of each other from time to time. Lack of elasticity means situation when many users while sharing one DC cannot change SLA at required level. In context of service availability, one DC for many users is also not perfect solution as technical, nature, and social incidents might affect the DC. As a result, cloud solution based on geographically distributed DCs looks preferable. The running project addressed to implementation of such the cloud is described in the paper.
The number of DCs in the world is steadily growing. There are many attempts in many areas to move applications from concrete DC to public cloud. Using multiple geographically distributed DCs looks preferable from reliability and resource availability points of view. The network connection between DCs included into the cloud should correspond with a SLA for the cloud: if a data transfer speed is serious priority, the data links might have a bandwidth of 100 Gbit or more. In order to implement the cloud, the special management system is required.
The number of modern approaches: Software Defined Storage (SDS), Software defined
Network (SDN), Network Function Virtualization (NFV), Infrastructure as Code (IaC) [
Gradual degradation with hardware or software malfunction.
Data storage features, including the long-term data storage with total volume up to 1 EB.
System Management Architecture of SGDD is implemented in form of separate program agents communicating with each other by the special designed protocol. System logical structure is shown in fig. 1. In the paper, the technical term program agent or agent means program daemon which is running in isolated operating environment. Any request to the agent and answer form the agent could be performed with appropriate protocol. Such implementation gives many advantages: independence for agent development: developer can use any programming language and/or library or versions of it; independence during system production: if one agent is down, other agents might continue to work, i.e. system is just partially degraded; simplification of horizontal scalability: it is possible to set up an additional agent instance with same functions in order to improve service bandwidth and to provide high availability and load balancing.
The system functioning principles are shown in fig. 1 as well. The user (client) can be signed up at the portal of registration and the accounting agent. After registration user is able to create a subscription where required virtual facilities are described. Such facilities may include virtual machines, virtual storages, virtual data links. All facilities may be accompanied by specific SLAs. Initially, all requests are headed to orchestration agent which does preliminary check of available resources. After that, user subscription request is routed to appropriate service agent: VM allocation agent, virtual data links allocation agent, storage allocation agent. Those service agents perform the creation of required virtual objects and send back the technical information how to access created virtual objects to the user.
For example, if creation of virtual storage with specific SLA is required, the storage allocation agent does create the CEPH cluster with required SLA including special gateway, which allows the user to read and write the data to and from virtual storage.
Virtual data links allocation agent does create new virtual links with specific SLA. SLA for
virtual links may include encryption/decryption, compression/decompression, etc. The implementation
of virtual data links is shown in fig. 2. The agent issues some commands for RYU SDN controller [
Main technical solutions within technical designing are: The system is based on Free and Open Source Software (FOSS) components.
Operating System: Naulinux (compatible with RedHat, Scientific Linux, CentOS) [
Data Storage - Software Defined Storage (SDS): CEPH [
Monitoring of physical and virtual infrastructure, billing data: Zabbix [
Visualization: Grafana [
Database keeping the hardware information, virtual objects information, detailed requests and answers information: PostgreSQL.
Communication within SGDD: RabbitMQ with special protocol developed.
Data transfer security: symmetric cryptography with OpenSSL and Quantum Key Distribution
(QKD) procedure [
Independence of external components changes (versions, polices, etc): own versions of Linux distribution (Naulinux) + code repository for all developed components.
Each type of service must be feasible for accounting/billing purposes.
Current debugging of the system is performed providing the following hardware test configuration: Several micro DCs consisting of servers [6 + 2 + 2] type HPE DL380 Gen10 8LFF CTO (each server has 2x Intel Zeon Gold 6130, main memory: 128 GB, HD storage 32 TB). Several switches: HP FF 5700-32XGT-8XG-2QSFP+ Switch.
Other communication equipment.
Automated deployment of the system has been implemented with SALTstack [
Main features of the project are: the use of FOSS components, system architecture based on the independent agents, QKD procedure, own code repository, automated deployment of the system [11]. An engineering infrastructure monitoring might permit to use data centers as dark data centers. Here dark data center means absence of permanent maintaining staff on the data center. It may be some technical persons are visiting such the data center to fix something by demand. All features together provide more security and reliability. The project is in active debugging stage now. The system is being prepared for a preproduction stage by first half of the 2019.
The development is performed in accordance with the contract № 03.G25.31.0229 “Development of new technological components for management systems of geographically distributed Data Centers” [11] P.V. Fedchenkov et al // APPROACHES TO THE AUTOMATED DEPLOYMENT OF THE CLOUD INFRASTRUCTURE OF GEOGRAPHICALLY DISTRIBUTED DATA CENTERS // these proceedings.