Main Page: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| Line 1: | Line 1: | ||
=NEWS= | =NEWS= | ||
==Example of my process of migration CLOUD== | ==Example of my process of migration CLOUD== | ||
[[File:Diagram-migration-ORACLE-KVM-v2.drawio.png]] | [[File:Diagram-migration-ORACLE-KVM-v2.drawio.png]] | ||
| Line 45: | Line 27: | ||
Total = 15 man-days | Total = 15 man-days | ||
==How to improve your application in the cloud == | |||
== | [[File:WebModelDiagram.drawio.png]] | ||
[ | *Formalize your infrastructure as much as possible for more flexibility, low complexity and less technology lock. | ||
*Use a name server able to handle the position of your customers like GDNS. | |||
*Use a minimal instance and use a network 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. | |||
*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. | |||
*... | |||
*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 | |||
==LAB CLOUD== | ==LAB CLOUD== | ||
I want to share my [[LAB project]].<br> | I want to share my [[LAB project]].<br> | ||
| Line 166: | Line 161: | ||
*[https://www.silkhom.com/barometre-2021-des-tjm-dans-informatique-digital/ IT] | *[https://www.silkhom.com/barometre-2021-des-tjm-dans-informatique-digital/ IT] | ||
*[http://www.journaldunet.com/solutions/emploi-rh/salaire-dans-l-informatique-hays/ IT] | *[http://www.journaldunet.com/solutions/emploi-rh/salaire-dans-l-informatique-hays/ IT] | ||
==Recent attacks ;)== | |||
[https://infocepo.com/attack-map attack map] : Virtual position from people trying to attack my CLOUD. | |||
Revision as of 22:27, 12 March 2022
NEWS
Example of my process of migration CLOUD
- 1.5 days: infra audit (82 clustered services) (audit own tool)
- 1.5 days: physical and virtual target CLOUD architecture diagram
- 1.5 days: construction of 2 CLOUD (physics)
- 1.5 days: installation of the 2 CLOUDs
- 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
How to improve your application in the cloud
- Formalize your infrastructure as much as possible for more flexibility, low complexity and less technology lock.
- Use a name server able to handle the position of your customers like GDNS.
- Use a minimal instance and use a network 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.
- 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.
- ...
- 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
LAB CLOUD
I want to share my LAB project.
CLOUD vs HW
| Function | KUBERNETES | OPENSTACK | AWS | Bare-metal | HPC | CRM | OVIRT |
| DEPLOY | HELM/ANSIBLE/SH | HELM/ANSIBLE/SH | TERRAFORM/CLOUDFOUNDATION | 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 | 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 | GLUSTERFS/SAN |
CLOUD REF
aws-azure-gcp service comparison
Top Infrastructure model
IT salaries
Recent attacks ;)
attack map : Virtual position from people trying to attack my CLOUD.