Difference between revisions of "Educaship Proxmox"

Revision as of 16:03, 13 May 2024

Educaship Proxmox (hereinafter, #The Cloud) is the combination of Proxmox Virtual Environment instances, those software packages that support them, as well as complete documentation for all of them that students and other customers of Educaship may utilize in their vocational skills and career development.

Quadruple Objective

#The Cloud shall serve four objectives, from which (a) the #Technology Stack and (b) #Learning Material are primary and important equally.

Learning Material

#The Cloud shall be a collection of learning materials for those customers who would like to learn and, potentially, get prepared for their practice work in #The Cloud. Specifically, that means that #The Cloud shall:

Be fully documented at the CNM Lab for those students who have a work-alike practice.
Be well-documented without security-sensitive details at the CNMCyber.com for those students who would like to learn about #The Cloud.

Marketing Resource

#The Cloud shall be used as resource in marketing of Educaship products. Particularly, we plan to introduce events such as "Guided Tour to Educaship Proxmox Cloud" and "State of Educaship Proxmox Cloud".

Technology Stack

#The Cloud shall technologically support functionality, usability, reliability, performance, security, scalability, and user satisfaction of Opplet, which is the technology where the end-users are served.

Work-Alike Playground

#The Cloud shall be a collection of software for those customers who would like to have a work-alike practice in #The Cloud. Specifically, that means that #The Cloud shall:

Use various software; the students shall have opportunities to practice with as many popular COTS open-source packages as possible.
Have advanced backup and recovery features; #The Cloud shall be resistible against incidents accidentally caused by the learners.
Accommodate hands-on assignments during which the learners can test functionality of existing #Technology Stack and can experiment with new applications.

Instances

Currently, #The Cloud consists of the #Federated VE and one #Peripheral VE. #We will consider #Adding More VEs when such a need emerges.

Federated VE

The federated part of #The Cloud is called CNM Bureau Farm and is based on three metal servers of Bureau Infrastructure. It utilizes #Server-Level HA and Ceph storage.

Peripheral VE

The peripheral part of #The Cloud is called CNM Lab Farm and is based on one metal server of Lab Infrastructure.

Adding More VEs

When #We need more resources, #We plan to add more instances similar to #Peripheral VE to the #Federated VE.

High Availability

Server-Level HA

The #Federated VE features high availability (HA) at the server level. If one or two of its infrastructure nodes fail, the remaining working node should still perform the work. This feature is implemented while utilizing the ha-manager tool of #PVE.

Application-Level HA

We don't plan to additionally cluster those applications that are located at the #Federated VE. At the application level, however, we plan to cluster those applications that are in production and are not deployed for experiments.

We envision that each of those clusters would feature:

Educaship HAProxy deployed at the #Federated VE sending outside world requests to one of the application instances.
At least three identical application instances deployed at the #Peripheral VE. If one or two of these instances fail, the remaining working instance should still perform the work. At the same time, if the #Peripheral VE fail, the application would not be available.
Some #Distributed Application Storage.

HA-Less Applications

Functionality Projects

Jitsi Functionality

Educaship Jitsi, which is Jitsi software deployed at Opplet, is used for webconferencing. Currently, we use some instance outside of #The Cloud because of challenges as follows. We have multiple Jitsi installations, one of which is in Docker. In this installation, there is no sound at all. Also, when updating Docker, a conference is not created.

Openness to the World

Educaship pfSense, which is pfSense software deployed at Opplet, is used as a firewall at #Federated VE. To utilize pfSense better, we consider clustering VMs at #Peripheral VE and placing HAProxy and similar proxies behind pfSense on the #Federated VE.

We are experiencing some issues obtaining SSL certificates for our sites running behind Pfsense. Due to the absence of the certificate, the service becomes completely unavailable.

VM Automation

We would like #Peripheral VE and #Peripheral VE only to create a VM for each VM customer automatically. In some cases, we have used Ansible. For that purpose, we tentatively plan to establish Educaship Ansible and Educaship Terraform. However, we are open to any other solution as well.

Storage Projects

Backup and Recovery Design

We also consider advancing the whole enterprise-wide backup and recovery system, which possibly, would be called Opplet Backup.

Backup and Recovery Tools

For backups and recovery,

Educaship Proxmox Backup, which is Proxmox Backup Server software deployed at Opplet, is used at #Federated VE.
Educaship RAID, which is RAID software deployed at Opplet, is used at #Peripheral VE.

File Storage, Library, or Repository

Our various applications may utilize the same files. We are looking for a solution for these websites' files to have a shared storage or library. We tried GlusterFS, but it seemed too slow to us. We copied the files to this storage for almost a week, and as a result, the website did not work.

We envision that the solution will play a role similar to the role of Wikimedia Commons. The Commons is a media repository of images, sounds, videos and other media that various Wikimedia Foundation projects use.

Storage Distributed in VM Clusters

We are looking for solutions for distributed storage available to those applications that are installed on those VMs that are clustered on the #Peripheral VE. We have several applications such as Educaship Moodle or Educaship MediaWiki that use Educaship MariaDB; their databases are combined in a Galera Cluster, which more or less satisfies our needs. We would like to explore other options and find solutions for those applications such as Educaship GitLab that don't use Educaship MariaDB.

Service Projects

Monitoring Design

We consider advancing the whole enterprise-wide monitoring system, which possibly, would be called Opplet Monitor.

Particularly, we would like to decide where to locate monitoring tools -- (a) on #Federated VE, (b) on #Peripheral VE, (c) outside of the servers that serve #The Cloud, or (d) some combination of something above.

Monitoring Tools

Our current monitoring doesn't satisfy us. We use Educaship Grafana for Proxmox. We would like to add several servers that do not use Proxmox, configure communication channels, and expand monitoring according to our tasks. We would also like to add Educaship Zabbix and Educaship Nagios.

Security Outline

Our security outline shall be reviewed and improved.

@@ Line 41: / Line 41: @@
 : We don't plan to additionally cluster those applications that are located at the [[#Federated VE]]. At the application level, however, we plan to cluster those applications that are in production and are not deployed for experiments.
-: We envision that those clusters would feature:
+: We envision that each of those clusters would feature:
 :* [[Educaship HAProxy]] deployed at the [[#Federated VE]] sending outside world requests to one of the application instances.
-:* At least three identical application instances deployed at the [[#Peripheral VE]]. If one or two of these instances fail, the remaining working instance should still perform the work.
+:* At least three identical application instances deployed at the [[#Peripheral VE]]. If one or two of these instances fail, the remaining working instance should still perform the work. At the same time, if the [[#Peripheral VE]] fail, the application would not be available.
-:*
+:* Some [[#Distributed Application Storage]].
 ===HA-Less Applications===