Main Page: Difference between revisions
No edit summary |
|||
Line 196: | Line 196: | ||
==REDHAT package browser== | ==REDHAT package browser== | ||
[https://access.redhat.com/downloads/content/package-browser REDHAT package browser] | [https://access.redhat.com/downloads/content/package-browser REDHAT package browser] | ||
==HA COROSYNC+PACEMAKER== | |||
Pour l'architecture je propose du classique : | |||
2 salles | |||
2FC / serveur (actif/actif) (SAN) | |||
2*10Gbit/s ethernet / serveur (actif/passif, possible actif/actif si PXE sur VLAN natif 0) | |||
VLAN IPMI (pour le fence) | |||
VLAN ADMIN qui doit être le VLAN natif si BOOTSTRAP par PXE (admin,provisionning,heartbeat) | |||
VLAN USER (les services applicatifs) | |||
NTP | |||
DNS+DHCP+PXE+TFTP+HTTP pour du provisionning en automatique | |||
PROXY (pour mise à jour ou sinon REPOSITORY interne) | |||
Choisir entre des clusteurs à 2 noeuds ou plus. | |||
Pour une archi 2 noeuds il faut un paramètrage à 2 noeuds sur COROSYNC et veiller à configurer un fence décallé de 10 secondes pour l'un des noeuds (sinon clusteur instable). | |||
Pour les services en écriture, ils seront de type actif/passif. | |||
Pour les autres services il est possible de faire de l'actif/actif. | |||
Pour les ressources DB il faut prévoir 8Go par base en général et doubler pour un clusteur à 2 noeuds (perte d'un noeud). | |||
Pour les ressources CPU, en règle général il n'y a pas de gros besoins. Astuce, pour des compressions dont les temps sont critiques utiliser PZSTD. |
Revision as of 10:44, 22 June 2022
My name is Antonio DA SILVA PACHECO (CV_PACHECO Website LINKEDIN).
With this site, I want to share my projects.
NEWS
CLOUD LAB
I want to share my LAB project.
Servers audit
I made ServerDiff.sh script to audit servers. You can track configuration drift. You can check if your environments are the same.
CLOUD migration example
- 1.5 days: infra audit (82 clustered services) (audit own tool)
- 1.5 days: physical and virtual target CLOUD architecture diagram
- 1.5 days: physical compliance of 2 CLOUD (6 hypervisors, 6TB memory)
- 1 days: installation of the 2 CLOUD
- .5 day: stability check
ACTION | RESULT | OK/NOK |
Disable all nodes minus one. (maintenance mode) | All resources started whitout disruption. | |
Activate all nodes. Power off all nodes minus one, different from the previous test. | All resources started. | |
Power off simultaneous all nodes. Power on simultaneous all nodes. | All resources started on all nodes. |
- 1.5 days: CLOUD automation study
- 1.5 days: 6 templates (2 CLOUD, 2 OS, 8 environments, 2 versions)
- 1 day: migration diagram
- 1.5 days: 138 lines of industrialization code for migration (migration own code)
- 1.5 days: process stabilization
- 1.5 days: CLOUD benchmark vs old INFRA
- .5 days: calibration of unavailability time per unit migration
- 5 minutes (effective load): 82 VM (env, os, application_code, 2 IP)
Total = 15 man-days
CLOUD improvement
- Formalize your infrastructure as much as possible for more flexibility, low complexity and less technology lock-in.
- Use a name server able to handle the position of your customers like GDNS.
- Use a minimal instance and use a network load balancer like LVS. Monitor the global load of your instances and add/delete dynamically as needed.
- Or, many providers have dynamic computing services. Compare the prices. But take care about the technology lock-in.
- Use a very efficient TLS decoder like the ATS decoder without blocking.
- Use very fast http cache like VARNISH.
- Use a big cache for big files like ATS.
- ...
- Use serverless service for standard runtimes like Java, Python and PHP. But beware of certain incompatibilities and a lack of consistency over time.
- ...
- Each time you need dynamic computing power think about load balancing or native service from the providers (caution about providers services!)
- ...
- Try to use open source STACKs as much as possible
- ...
- Use cache for your databases like MEMCACHED
CLOUD vs HW
Function | KUBERNETES | OPENSTACK | AWS | Bare-metal | HPC | CRM | OVIRT |
DEPLOY | HELM/ANSIBLE/SH | TERRAFORM/ANSIBLE/SH/JUJU | TERRAFORM/CLOUDFOUNDATION/ANSIBLE/JUJU | ANSIBLE/SH | XCAT/CLUSH | ANSIBLE/SH | ANSIBLE/PYTHON/SH |
BOOTSTRAP | API/CLI | PXE/API/CLI | API/CLI | PXE/IPMI | PXE/IPMI | PXE/IPMI | PXE/API |
Router | API/CLI (kube-router) | API/CLI (router/subnet) | API/CLI (Route table/subnet) | LINUX/OVS/external | XCAT/external | LINUX/external | API |
Firewall | INGRESS/EGRESS/ISTIO | API/CLI (Security groups) | API/CLI (Security group) | LINUX (NFT) | LINUX (NFT) | LINUX (NFT) | API |
Vlan | DANM | API/CLI (VPC) | API/CLI (VPC) | OVS/LINUX/external | XCAT/external | LINUX/external | API |
Name server | coredns | dns-nameserver | Amazon Route 53 | GDNS | XCAT | LINUX/external | API/external |
Load balancer | kube-proxy/LVS(IPVS) | LVS | Network Load Balancer | LVS | SLURM | Ldirectord | |
Storage | many | SWIFT/CINDER/NOVA | S3/EFS/FSX/EBS | OPENSTACK SWIFT/XFS/EXT4/RAID10 | GPFS | SAN | NFS/SAN |
CLOUD REF
CLOUD providers
Infrastructure example
IT salaries
REDHAT package browser
HA COROSYNC+PACEMAKER
Pour l'architecture je propose du classique :
2 salles 2FC / serveur (actif/actif) (SAN) 2*10Gbit/s ethernet / serveur (actif/passif, possible actif/actif si PXE sur VLAN natif 0) VLAN IPMI (pour le fence) VLAN ADMIN qui doit être le VLAN natif si BOOTSTRAP par PXE (admin,provisionning,heartbeat) VLAN USER (les services applicatifs) NTP DNS+DHCP+PXE+TFTP+HTTP pour du provisionning en automatique PROXY (pour mise à jour ou sinon REPOSITORY interne)
Choisir entre des clusteurs à 2 noeuds ou plus.
Pour une archi 2 noeuds il faut un paramètrage à 2 noeuds sur COROSYNC et veiller à configurer un fence décallé de 10 secondes pour l'un des noeuds (sinon clusteur instable).
Pour les services en écriture, ils seront de type actif/passif. Pour les autres services il est possible de faire de l'actif/actif.
Pour les ressources DB il faut prévoir 8Go par base en général et doubler pour un clusteur à 2 noeuds (perte d'un noeud). Pour les ressources CPU, en règle général il n'y a pas de gros besoins. Astuce, pour des compressions dont les temps sont critiques utiliser PZSTD.