Skip to content
Snippets Groups Projects

Adding further information regarding the current AIMS setup

Merged Adding further information regarding the current AIMS setup
extra_aims2_logic into master
All threads resolved!
Merged Daniel Juarez Gonzalez requested to merge extra_aims2_logic into master
All threads resolved!
Compare
and
2 files
+ 24
− 2
Compare changes
  • Side-by-side
  • Inline
Files
2
docs/aims2/aims2architecture.md 0 → 100644
+ 21
− 0
# AIMS2 architecture
All AIMS instances are under the control of the [corresponding hostgroup](https://gitlab.cern.ch/ai/it-puppet-hostgroup-aims) which also takes care of putting the corresponding Teigi secrets in place.
Uploaded images are stored on an Oracle database, directly as blobs, as a form of getting delegated backups from the Oracle service.
AIMS2 servers have the following main components:
* An Apache server, which has a module corresponding to the AIMS2 server, therefore you can find related logs under `/etc/httpd/logs/`
* AIMS2 server, which logs in `/var/log/messages`. This is the main component of the whole system
* It deals with all requests from the clients
* `dnsmasq` component which serves as differentiation for received requests from the client machines. Depending on its architecture, the server provides a different bootloader.
* For unregistered machines, the differentiation is done on [the DHCP configuration](https://gitlab.cern.ch/network/cfmgr/blob/master/cfmgr_modules/hcp/shcp.pm) due to the clients not sending any DHCP option to AIMS servers.
* `aims2sync` keeps coherence between the database data and the local file system.
* It retrieves image blobs and stores them into the local file system under `/tftpboot/aims/boot/`
* It stores the specific `pxelinux` or `grub` configurations for clients under `/tftpboot/aims/config/`
* Keeps track of the synchronisation on the database when done with such tasks
* `aims2client` is the tool used to interact with the system, for new hosts, images or configurations
The system is based on a master-slave configuration. Note that 3 instances are expected for each environment, hence the hardcoded flags on the `aims2client` and database (i.e. `YYN` synchronisation on the server responses). The master is determined by the machine state (can be altered by removing the machine from `production` status on `roger`), if master is down, slave replaces it on the Load Balancer alias. Alias weights are determined on the hostgroup.