Montage d'un disque NVME sur AWS EC2
J'ai donc créé i3.large avec un disque NVME sur chaque nœud, voici comment procéder:
- lsblk -> nvme0n1 (vérifiez si nvme n'est pas encore monté)
- Sudo mkfs.ext4 -E nodiscard/dev/nvme0n1
- Sudo mount -o ignorer/dev/nvme0n1/mnt/mes-données
- / dev/nvme0n1/mnt/my-data ext4 par défaut, nofail, ignorer 0 2
- Sudo mount -a (vérifiez si tout va bien)
- Sudo redémarrer
Donc, tout cela fonctionne, je peux me reconnecter à l'instance. J'ai 500 Go sur ma nouvelle partition.
Mais après avoir arrêté et redémarré les ordinateurs EC2, certains d'entre eux sont devenus inaccessibles de manière aléatoire (avertissement AWS uniquement, vérification de l'état du test 1/2).
Quand je regarde les journaux qui expliquent pourquoi c'est inaccessible, cela me dit que c'est à propos de la partition nvme (mais j'ai fait Sudo mount -a pour vérifier si tout allait bien, alors je ne comprends pas)
Je n'ai pas exactement les journaux AWS, mais j'en ai quelques lignes:
Mauvais chiffre magique en super-bloc en essayant d'ouvrir
alors le superbloc est corrompu et vous pouvez essayer de lancer e2fsck avec un autre superbloc:
/ dev/fd/9: ligne 2: plymouth: commande introuvable
Arrêter et démarrer une instance efface les disques éphémères, déplace l'instance sur un nouveau matériel hôte et vous donne de nouveaux disques vides ... afin que les disques éphémères soient toujours vides après l'arrêt/le démarrage. Lorsqu'une instance est arrêtée, elle n'existe sur aucun hôte physique. Les ressources sont libérées.
Ainsi, la meilleure approche, si vous voulez arrêter et démarrer des instances, n’est pas de les ajouter à /etc/fstab, mais plutôt de les formater au premier démarrage et de les monter ensuite. Une façon de vérifier si un système de fichiers est déjà présent consiste à utiliser l'utilitaire file et grep sa sortie. Si grep ne trouve pas de correspondance, il renvoie false.
Le disque SSD NVMe de la classe d'instance i3 est un exemple de volume de stockage d'instance , également appelé Ephemeral [Disk | Volume | Conduire ]. Ils sont physiquement à l'intérieur de l'instance et extrêmement rapides, mais non redondants et non destinés à des données persistantes ... d'où "éphémères". Les données persistantes doivent se trouver sur un volume Elastic Block Store (EBS) ou un Elastic File System (EFS) , qui survivent tous deux à l'arrêt/au démarrage, aux pannes matérielles et à la maintenance.
La raison pour laquelle vos instances ne parviennent pas à démarrer n'est pas claire, mais nofail peut ne pas être à la hauteur de ce que vous attendez lorsqu'un volume est présent mais ne possède pas de système de fichiers. Mon impression a été que finalement il devrait réussir.
Mais vous aurez peut-être besoin de apt-get install linux-aws si vous utilisez Ubuntu 16.04. Ubuntu 14.04 NVMe n'est pas vraiment stable et non recommandé .
Chacune de ces trois solutions de stockage a ses avantages et ses inconvénients.
Le magasin d'instance est local, donc c'est assez rapide ... mais c'est éphémère. Il survit aux redémarrages durs et logiciels, mais pas aux cycles d'arrêt/démarrage. Si votre instance subit une panne matérielle ou si sa mise hors service est planifiée, comme cela arrivera finalement à tout le matériel, vous devrez arrêter et redémarrer l'instance pour la déplacer vers un nouveau matériel. Les instances réservées et dédiées ne changent pas le comportement du disque éphémère.
EBS est un stockage persistant, redondant, qui peut être détaché d'une instance et déplacé vers une autre (et cela se produit automatiquement lors d'un arrêt/démarrage). EBS prend en charge les instantanés à un point dans le temps, et ils sont incrémentiels au niveau des blocs. Vous ne payez donc pas pour le stockage de données qui n'ont pas changé entre les instantanés ... mais grâce à une excellente sorcellerie, vous n'avez pas suivre les instantanés "complets" et "incrémentaux" - les instantanés ne sont que des conteneurs logiques de pointeurs vers les blocs de données sauvegardés; ils sont donc essentiellement des instantanés "complets", mais facturés comme incrémentiels. Lorsque vous supprimez un instantané, seuls les blocs qui ne sont plus nécessaires pour restaurer cet instantané et tout autre instantané sont purgés du système de stockage principal (qui, de manière transparente pour vous, utilise Amazon S3).
Les volumes EBS sont disponibles en tant que volumes magnétiques SSD et Platinum, de nouveau avec des compromis en termes de coût, de performances et d'applications appropriées. Voir Types de volume EBS . Les volumes EBS imitent les disques durs ordinaires, à la différence que leur capacité peut être augmentée manuellement à la demande (mais pas diminuée) et peut être convertie d'un type de volume à un autre sans arrêter le système. EBS effectue l'intégralité de la migration des données à la volée, avec une réduction des performances mais aucune interruption. C'est une innovation relativement récente.
EFS utilise NFS, vous pouvez donc monter un système de fichiers EFS sur autant d'instances que vous le souhaitez, même dans les zones de disponibilité d'une région. La limite de taille pour tout fichier dans EFS est de 52 téraoctets et votre instance signalera en fait 8 exaoctets d'espace libre. L’espace disponible réel est, à toutes fins pratiques, illimité, mais EFS est également le plus cher - si vous aviez un fichier de 52 Tb stocké pendant un mois, ce stockage coûterait plus de 15 000 USD. Le maximum que j'ai jamais stocké a été d'environ 20 TiB pendant 2 semaines, m'a coûté environ 5 000 dollars, mais si vous avez besoin d'espace, celui-ci est là. Il est facturé à l'heure, donc si vous stockiez le fichier de 52 To pendant seulement quelques heures puis le supprimiez, vous paieriez peut-être 50 $. Le terme "Elastic" dans EFS fait référence à la capacité et au prix. Vous ne pré-approvisionnez pas d'espace sur EFS. Vous utilisez ce dont vous avez besoin et supprimez ce dont vous n’avez pas besoin, et la taille facturable est calculée toutes les heures.
Une discussion sur le stockage ne serait pas complète sans S3. Ce n'est pas un système de fichiers, c'est un magasin d'objets. À environ 1/10 du prix de l'EFS, S3 a également une capacité infinie et une taille maximale d'objet de 5 To. Certaines applications seraient mieux conçues en utilisant des objets S3, au lieu de fichiers.
S3 peut également être facilement utilisé par des systèmes extérieurs à AWS, que ce soit dans votre centre de données ou dans un autre cloud. Les autres technologies de stockage sont destinées à être utilisées dans EC2, bien qu'il existe une solution de contournement non documentée } permettant à EFS d'être utilisé en externe ou entre régions, avec des proxies et des tunnels.
Vous pouvez trouver utile une nouvelle famille d'instances EC2 équipée d'un stockage NVMe local: C5d.
Voir l'article de blog d'annonce: https://aws.Amazon.com/blogs/aws/ec2-instance-update-c5-instances-with-local-nvme-storage-c5d/
Quelques extraits du billet de blog:
- Vous _ {vous n’avez pas à spécifier de mappage de périphérique en bloc dans votre AMI} ou lors du lancement de l’instance; le stockage local apparaîtra sous la forme d'un ou de plusieurs périphériques (/ dev/nvme * 1 sous Linux) après le démarrage du système d'exploitation invité.
- Outre l'ajout de stockage local, les C5 et C5d partagent les mêmes spécifications.
- Vous pouvez utiliser n’importe quelle AMI incluant des pilotes pour Elastic Network Adapter (ENA) et NVMe.
- Chaque périphérique NVMe local est chiffré de manière matérielle à l'aide du chiffrement par blocs XTS-AES-256 et d'une clé unique.
- Les périphériques NVMe locaux ont la même durée de vie que l'instance à laquelle ils sont attachés et ne restent pas après l'arrêt ou la fin de l'instance.
Je viens d'avoir une expérience similaire! Mon instance C5.xlarge détecte un EBS comme nvme1n1. J'ai ajouté cette ligne dans fstab.
/dev/nvme1n1 /data ext4 discard,defaults,nofail 0 2
Après quelques redémarrages, cela semblait fonctionner. Il a fonctionné pendant des semaines. Mais aujourd’hui, je viens d’être averti que cette instance n’a pas pu être connectée. J'ai essayé de le redémarrer à partir de la console AWS, pas de chance, le coupable est le fstab. Le montage sur disque a échoué.
J'ai adressé le ticket au support AWS, pas encore de retour. Je dois démarrer une nouvelle instance pour récupérer mon service.
Dans une autre instance de test, j'essaie d'utiliser UUID (get par commande blkid) au lieu de/dev/nvme1n1. Jusqu'à présent, semble toujours fonctionner ... va voir si cela cause un problème.
Je mettrai à jour ici les commentaires du support AWS
================ EDIT avec mon correctif ============
AWS ne me donne pas encore de commentaires, mais j'ai trouvé le problème. En fait, dans fstab, peu importe ce que vous montez/dev/nvme1n1 ou UUID, peu importe. Mon problème est, mon ESB a des erreurs dans le système de fichiers. Je l'ai attaché à une instance puis exécuté
fsck.ext4 /dev/nvme1n1
Après avoir corrigé quelques erreurs de système de fichiers, mettez-les dans fstab, redémarrez, plus aucun problème!