Main Page

Welcome to my technical WIKI. (I have extra time for CLOUD projects CV_PACHECO)

CLOUD LAB

I want to share my LAB project.

INFRA 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 REF

CLOUD providers

• aws-azure-gcp service comparison

Infrastructure example

• Wikipedia

IT salaries

• Top technical certifications
• IT
• IT

REDHAT 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.