397 liens privés
curl -X POST --data 'instance_type=m3.medium&location=eu-central-1' 'http://ec2-price.com/'
0.079
Ceci est notable.
Avant, il fallait recréer l'instance.
Pour ceux qui veulent commencer à jouer rapidement avec terraform pour démarrer/provisionner des machines sur ec2...
Les AMI Debian Jessie.
Petite formule saltstack pour faire utiliser les 3/4 de la RAM à la JVM:
"""
Xmx: {{ (((grains.mem_total|int) 3) / 4)|round|int }}M
Xms: {{ (((grains.mem_total|int) 3) / 4)|round|int }}M
"""
J'ai positionné cela dans les pillars.
C'est inspiré de https://mywushublog.com/2013/09/postgresql-salt-state/ (https://jeekajoo.eu/links/?crzrTg)
Cela évite d'avoir à se palucher un tuning manuel pour des machines dont les capacités mémoire sont différentes. Exemple sur ec2:
- m3.2xlarge = 30 G
- c3.2xlarge = 15 G
- c3.xlarge = 7.5 G
- m3.medium = 3.75 G
- ....
$ aws ec2 describe-security-groups --filter Name=ip-permission.cidr,Values=X.X.X. --query 'SecurityGroups[].GroupName'
Le pourquoi de sa méthode repose dans cette citation:
"""
In general there are two ways to build AMIs: Spinning up a new instance, customize it and create a snapshot or build the AMI from scratch.
The first option seems to be the most common case. There are several tools like packer or Netflix' aminator but since it requires to actually boot a existing AMIs, it has a few downsides. For once it requires a existing AMI which might include things you don't need but I'm more worried about the fact that it requires to actually boot a machine. This breaks the clean separation of build- and runtime and might mess up your build artefacts. Think logfiles, dhcp/cloud-init configuration and so on. Sure, you can clean up those things but I prefer avoiding it in the first place by never entering the runtime before actual deployment.
"""
Pas encore lu.
Complémentaire avec l'article d'instagram: https://jeekajoo.eu/links/?-zo-hA
par un gars de chez netflix
slides: http://fr.slideshare.net/brendangregg/performance-tuning-ec2-instances
ec2 standard -> ec2 vpc
certains tirent profits des ssd ephemeres fournis avec les c3 pour les mettre en tant que cache devant des ebs.
Comme on a aucune idée de connaitre les perfs disque et réseau des instances ec2 (sauf en testant par soi-même), certains on fait des benchs.
Les résultats de ces benchs, qui testent les perfs réseau, montrent qu'on a intérêt à faire attention dans les choix d'instance....
"""
In our experiment we saw that the network performance of m1.large was lower than that of m1.medium. As per AWS documentation, the network performance of both m1.medium and m1.large is ‘moderate’ so we expected it to be similar. We also see that the network bandwidth of m3.medium is less than that of m1.small even though AWS documentation says that the network performance m3.medium is ‘moderate’ while that of m1.small is ‘low’. Network performance often depends on various scenarios like the network load on the actual hardware on which the VM is running. This might be a possible reason for this anomaly.
"""
voir aussi https://jeekajoo.eu/links/?GblCKw pour des comparaisons perf cpu/mem/disk
benchmark de différentes tailles d'instances chez différents fournisseurs de claoud' computing
page officielle des coûts d'instance EC2 amazon
(quand http://www.ec2instances.info/ n'est plus à jour ><, comme aujourd'hui )
Ce merveilleux site permet de comparer les specs/prix des instances EC2 par région.
disponibilité de l'ensemble des régions amazon ec2.