Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "GGUS Architecture"

From EGIWiki
Jump to navigation Jump to search
m
 
(One intermediate revision by the same user not shown)
Line 4: Line 4:
*3. Database (oracle based) for tickets and Portal data
*3. Database (oracle based) for tickets and Portal data


Every layer is constructed for three independent environments: development, testing and production. The development process is restricted by development and testing environments. All scripts are going into test (checking software quality) and production by using standard package management software for operating system. Hence, the announced downtime is reduced, but cannot be completely avoided because of workflows update (intra ARS Remedy coding).  
Every layer is constructed for three independent environments: development, testing and production. The development process is restricted by development and testing environments. <br>
All scripts are going into test (checking software quality) and production by using standard package management software for operating system. Hence, the announced downtime is reduced, but cannot be completely avoided because of workflows update (intra ARS Remedy coding).  


Vision for high availability (HA) GGUS Service is to bring the GGUS architecture into the highly available infrastructure. Currently this task is already done for all GGUS hosts, except Production environment and consists of the following components:
All the GGUS architecture is in a highly available infrastructure. This task is done for all GGUS hosts and consists of the following components:


;1. Virtualisation
;1. Virtualisation
Line 28: Line 29:
*Database synchronization is done by replication without clustering (cheap solution)
*Database synchronization is done by replication without clustering (cheap solution)
*Switching between replicated hosts is partly automated  
*Switching between replicated hosts is partly automated  
*Are under on Call Duty Service (24/7) monitoring
*Are under On-Call-Duty service monitoring (24/7)
 
Current situation cannot allow moving production into new HA environment, because of multiple changes into Web frontend part. The decision is do not make this changes, but to migrate into xGUS platform (used by NGIs) and after that move both into HA environment. For this moment, the xGUS framework is prepared for migration and for GGUS Web frontend integration. Oracle Production Machines are still based on Oracle Real Application Clusters (RAC), but also have prepared virtual machines. The plan is to be ready during this year.

Latest revision as of 13:44, 23 April 2018

The GGUS architecture consists of the following three layers:

  • 1. Web-based Client (based on httpd and php scripts) with VOMS user synchronization interface
  • 2. Logic Server (based on ARS Remedy) with Web service (based on apache tomcat) and Email interface
  • 3. Database (oracle based) for tickets and Portal data

Every layer is constructed for three independent environments: development, testing and production. The development process is restricted by development and testing environments.
All scripts are going into test (checking software quality) and production by using standard package management software for operating system. Hence, the announced downtime is reduced, but cannot be completely avoided because of workflows update (intra ARS Remedy coding).

All the GGUS architecture is in a highly available infrastructure. This task is done for all GGUS hosts and consists of the following components:

1. Virtualisation
  • Is based on VMWare ESX Clusters
  • Has redundant connection to Networking and Storage (which is also complete redundant)
  • Include two completely independent instances: Campus South and North (around 12 km in between)
  • All hosts are virtual machines
  • Daily virtual machines backup
2. Networking
  • 10 Gigabit connection
  • Is redundant between Campus North and South
  • Is located on DMZ (perimeter or demilitarized network)
  • Use redundant Domain Name Servers (DNS)
  • Internet Connection use two different Internet service providers
3. Hosts
  • Every layer is hosted under own virtual host
  • Based on Redhat Linux 6 operating system
  • Software configuration is done by the configuration management tool (cfengine v.3)
  • Database synchronization is done by replication without clustering (cheap solution)
  • Switching between replicated hosts is partly automated
  • Are under On-Call-Duty service monitoring (24/7)