AWS re:Invent 2013 (2.1/2) : Use Cases – Créer son NAS sur AWS : NFS, CIFS & GFS (GlusterFS)

NAS sur AWS : NFS sous Linux

Cet article fait suite à la synthèse des sorties annoncées lors du summit AWS re:Invent 2013 qui s’est déroulé cette année du 12 au 15 Novembre à Las Vegas. Nous allons aborder dans cet article la mise en place d’un NAS (Network Attached Storage) sur une infrastructure AWS (VPC ou EC2 standalone) afin de partager des fichiers via le réseau selon les protocoles NFS (Network File System) pour Unix et CIFS (Common Internet File System) pour Windows. Nous mettrons dans ce cadre un cluster inter-AZs (Availability Zone/Zone d’Accessibilité) basé sur PaceMaker et DRBD. Nous aborderons une alternative basée sur GFS (GlusterFS) afin de mettre à disposition des instances EC2 de votre infrastructure vos fichiers de manière transparente et distribuée. Cet article se base sur une présentation très intéressante de Craig Carl (AWS).

Vous pourrez retrouvez également les autres articles de cette série consacrée au retour d’expérience du summit AWS en suivant ces liens Optimisation de son cluster EMR (Elastic MapReduce)Accélérer la délivrance de son contenu via CloudFront et Route 53 ou bien encore Concept du monitoring à grande échelle avec S3 et EMR par Netflix. C’est parti pour l’article 2.1 de la série ! :o)

UPDATE : Une erreur s’est glissée dans mon article. Suite à une remarque pertinente d’un lecteur, il s’avère que GFS != GlusterFS. GFS est le filesystem cluster de RedHat, tandis que GlusterFS (qui appartient aussi à RedHat) est un FS distribué. Je pensais que GFS était un acronyme condensé de GlusterFS et j’avais tort. Cet article traite donc bien de GlusterFS.

Créer son NAS sur AWS : NFS, CIFS & GFS (GlusterFS)

Tout d’abord avant d’entrer dans le vif du sujet, une question revient régulièrement : pourquoi AWS ne propose-t-il pas un NAS en standard dans leur offre ? La réponse des intéressés est que S3 peut répondre à 90% des use-cases en termes de partage de fichiers. Il reste néanmoins les 10% restants, que je croise régulièrement, qui utilisent des composants qui ne supportent pas en natif le dialogue avec S3, qui ne veulent pas investir dans le développement d’un plugin S3 spécifique pour leurs outils et qui ne veulent pas non plus utiliser en production des « émulations » de systèmes de fichiers de type s3fs basé sur FUSE pour des questions de performances et de stabilité (notamment dans les cas où les applications doivent modifier les fichiers directement sur le disque, ce qui n’est effectivement pas le cas « idéal » pour l’utilisation d’un object storage en backend). Il reste donc un certain nombre de cas où le NAS devient indispensable.

Les solutions proposées ci-dessous pour la mise en place d’un NAS ne résolvent pas pour autant un des problèmes inhérents au NAS et qu’il est bon de rappeler : la gestion des petits fichiers, plus petits que la taille des blocs utilisés. En effet, ils vont consommer de l’espace inutilement sur le disque, ne vont pas bénéficier de l’accélération due au striping car ne pourront être écrits/lus en parallèle sur plusieurs disques, … Donc c’est toujours le même problème.

Maintenant que les présentations sont effectuées, passons au vif du sujet ! :o)

Interfaces réseau et bande passante

Le premier élément à prendre en compte dans la mise en place d’un NAS est la bande passante des interfaces réseau de l’instance EC2 qui va supporter le partage des fichiers : il faut choisir un type d’instance qui va assurer un débit suffisant au niveau des interfaces IP publique et EBS.

NAS sur AWS : débit sur interface IP publique

NAS sur AWS : débit sur interface IP publique

NAS sur AWS : débit sur interface EBS

NAS sur AWS : débit sur interface EBS

Les images ci-contre indiquent les caractéristiques des différentes catégories d’instances en termes de bande passante :

  • Concernant l’interface publique, le pré-requis est de prendre au minimum une famille proposant des performances « moderate ».
  • Au niveau de l’interface avec les EBS, la famille doit avoir l’option EBS Optimized disponible : attention, cette option est au niveau de l’EC2 et est différente de la notion de Provisioned IOPS volumes (EBS). Il est d’ailleurs conseillé d’utiliser les 2 en même temps (EBS Optimized pour les instances EC2 & Provisioned IOPS volumes pour les volumes EBS).

EBS-optimized Instances

For a low, additional, hourly fee, you can launch selected Amazon EC2 instances types as EBS-optimized instances. EBS-optimized instances deliver dedicated throughput between Amazon EC2 and Amazon EBS, with options for 500 Mbps and 1000 Mbps depending on the instance type used. We recommend using Provisioned IOPS volumes with EBS-optimized instances or instances that support cluster networking for applications with high storage I/O requirements.

A noter que les instances, placées dans un même groupe de placement et supportant le Cluster Networking, peuvent profiter d’une bande passante importante de 10Gigabit, qui est partagée dans ce cas entre l’interface IP publique et l’interface EBS.

Pour plus d’informations sur les différents types d’instances EC2 disponibles, leurs caractéristiques et leurs options, vous pouvez suivre ce lien.

EBS Vs Ephemeral

Grand classique :

  • Ephemeral disks optimisés pour les sequential IOs,
  • Volumes EBS optimisés pour les random IOs.

De plus, les temps de latence au niveau des Ephemeral disks sont meilleurs. On en arrive à la conclusion qu’il faut stocker les données sur les disques éphémères. Il reste alors à ajouter une réplication DRBD asynchrone entre les disques éphémères et les volumes EBS pour assurer la durabilité des données. Les disques éphémères jouent alors le rôle d’un cache.

Les instances de type hs1, et également les nouvelles i2, sont tout à fait adaptées pour ce genre de use-cases avec leurs disques éphémères SSD et leur capacité en IOPs.

Comme précisé dans l’article précédent, il est à noter quelques tips utiles concernant les instances optimisées en IOPs et en particulier construites sur des disques SSD. Il s’agit de tips pour les hs1, mais qui ne manqueront pas de s’appliquer aux i2 :

  • Instance Store with HS1 Instances,
  • Disk Initialization (zero-fill),
  • Setting the Memory Limit (Linux-based Amazon Machine Images => CONFIG_XEN_MAX_DOMAIN_MEMORY),
  • Setting the User Limit (ulimit) (Linux-based Amazon Machine Images => default ulimit of 1024 to 2048).

Stars and Stripes

NAS sur AWS : Ephemeral Disks backed with DRBD to EBS

NAS sur AWS : Ephemeral Disks backed with DRBD to EBS

Maintenant pour améliorer les performances en IOPs, il faut créer un array de disques ou RAID striping de type RAID0, c’est à dire sans calcul de parité comme en RAID5, ni mirroring comme en RAID1. En effet, la durabilité des volumes EBS est déjà assurée par réplication réseau (3 fois) donc par du RAID1.

A noter que le striping doit être appliqué autant au niveau des disques éphémères que des volumes EBS pour bénéficier des avantages à tous les niveaux.

Cela va permettre :

  1. de pouvoir écrire et lire la donnée éclatée sur plusieurs disques en parallèle (donc des accès à la donnée plus rapides),
  2. d’avoir une meilleure bande passante générale « instance EC2 – volumes EBS », pour peu que l’on ait accordé la somme des bandes passantes des volumes EBS avec la bande passante de l’interface EBS de l’instance EC2,
  3. d’avoir plus de stockage disponible (si besoin au niveau des volumes EBS).

Pour agréger les volumes EBS, il a été proposé mdadm. Personnellement j’utilise LVM2 (Logical Volume Manager… 2). Tout est possible ! :o)

Précision concernant le snapshot d’un array de disques : il faut évidemment arrêter les écritures le temps d’initialiser le snapshot et, ce, sur tous les volumes EBS en même temps (sous peine d’avoir une incohérence au niveau des données sauvegardées). A noter que le fait d’effectuer un snapshot, même lorsqu’il est initialisé et que les volumes EBS sont à nouveau accessibles en écriture, ralentit les performances sur les accès : il vaut mieux donc effectuer les backups lors de « périodes creuses ».

Seconde précision concernant le nombre de volumes EBS à intégrer au RAID0 : cela dépend du type d’instance, mais on peut envisager 8 disques, voire 16 (au max) pour les plus grosses instances.

Multi-AZs

NAS sur AWS : NFS sous Linux

NAS sur AWS : NFS sous Linux

Il nous reste maintenant à prendre en compte la résilience de notre NAS au niveau d’une région en utilisant plusieurs AZs (Availability Zone ou Zone d’Accessibilité). Cela va être rendu possible à nouveau via DRBD pour la synchronisation des données, mais cette fois-ci de manière synchrone.

Pour plus d’informations sur les différentes options de mirroring de DRBD, vous pouvez suivre ce lien.

Il reste maintenant qu’en cas de défaillance du noeud principal, il faut que le noeud passif en hot standby prenne le relai ! C’est le rôle de PaceMaker que de monitorer l’état de santé du noeud primaire et de promouvoir le secondaire en cas de problème. Pour ce faire, il récupère l’ENI (Elastic Network Interfaces) de l’instance down et l’attache à celle qui conserve la donnée répliquée, dans le cas d’un VPC. Dans le cas d’une instance EC2 dans le réseau classique (en fait je dirais plutôt ancien, car maintenant le standard c’est le VPC), PaceMaker récupère l’IP publique (EIP) pour l’attacher à l’instance promue ! Pour customiser PaceMaker de la sorte, il faut ajouter un script dans les « ressources externe » de Pacemaker afin de définir l’action à réaliser, spécifique à la plateforme AWS. Ce script « doit être » ou « est déjà » mis à disposition par AWS suite au summit : surveillez les mises à jour de leurs ressources ! :o)

A noter que la réplication synchrone inter-AZs risque d’induire une latence, à surveiller donc pour valider que le NAS fonctionne bien de manière optimale.

NAS sur AWS : CIFS sous Windows

NAS sur AWS : CIFS sous Windows

Windows et DFS

Nous avons abordé pour l’instant le cas des environnements UNIX. Il est également possible de réaliser le même travail sous Windows avec DFS. Cela n’est apparemment possible qu’à partir de la version Windows Server 2012, même si il me semble que ce protocole était disponible dans les précédentes versions. Mais il doit bien y avoir une raison et cela dépasse mes compétences en MS.

GlusterFS

Configuration GFS

Configuration GFS

Reste maintenant l’option GFS, un système de fichiers distribué. Toute la « magie » de GFS réside dans le client : stateless, c’est lui qui va identifier les serveurs avec qui il doit dialoguer et rendre ainsi transparent pour l’utilisateur les échanges avec le cluster. Il est évidemment possible, lors de la définition des réplicas, de faire pointer vers des instances dans des AZs différentes pour assurer une résilience du système. Vous pourrez trouvez ci-contre quelques lignes de configuration pour la partie cliente et pour la partie serveur. Cette configuration est tirée de la présentation AWS citée en début d’article, comme le reste des illustrations.

Si la mise en place d’un GlusterFS ou d’une des solutions précédemment exposées vous semble trop complexe ou trop coûteuse par rapport à votre besoin, des éditeurs de solutions proposent des services managés basés sur ces technos, comme SoftNAS qui utilise plutôt les techniques de réplication DRBD/PaceMaker ou bien Zadara Storage qui propose une solution basée sur GFS (indications techniques données par notre présentateur, je n’ai pas eu le temps d’étudier les solutions en détail :o)). Une liste plus complète de fournisseurs de solutions NAS est disponible dans les slides linkés en début d’article. Cela peut être une piste si vous préférez ne pas avoir à gérer vous même votre NAS. Vous pouvez aussi aller voir directement les solutions des ISVs (Independent Software Vendors) disponibles dans la AWS Marketplace > Rubrique Software Infrastructure pour chercher ce qui vous intéresse.

Conclusion

Voilà donc un tour d’horizon des solutions possibles en termes de NAS. Il est vrai que, quand cela est possible, il est intéressant d’utiliser les services managés proposés par AWS, comme S3 pour ne pas le citer, et de bénéficier des avantages en termes de disponibilité, durabilité, … Mais quand la solution que vous construisez nécessite la mise à disposition de fichiers partagés entre vos instances et qu’elle n’est pas compatibles avec S3, ni avec du FUSE over S3, il faut utiliser un NAS : soit avec la bonne vieille méthode du DIY (Do It Yourself) et en acceptant les coûts induits en termes d’instances EC2/volumes EBS et de maintenance, soit en confiant la mise en place et l’exploitation du NAS à d’autres sociétés via des services managés basés sur ceux d’AWS.

Frédéric FAURE @Twitter @Ysance

3 commentaires pour AWS re:Invent 2013 (2.1/2) : Use Cases – Créer son NAS sur AWS : NFS, CIFS & GFS (GlusterFS)

  • J’ai pas mal de questions ! On a envisagé ce type de setup (RAID0, DRBD) il y a quelques années sur EC2, mais on a abandonné pour les raisons suivantes. Je me demandes si ces raisons sont toujours d’actualité, ou si EC2 a évolué depuis.

    1. Les snapshots

    Comme tu le soulignes, il faut arrêter les écritures au moment où on fait un snapshot du RAID, sous peine d’avoir des snapshots incohérents (puisque EBS ne permet pas de faire un snapshot de plusieurs volumes simultanément). Le problème, c’est que dans notre cas, le snapshot dure « un moment » (quelques secondes à quelques dizaines de secondes); donc quand on met bout à bout l’arrêt des écritures, le flush du cache, et le snapshot, cela peut faire facilement une minute, ce qui est une interruption de service inacceptable dans notre cas (surtout lorsqu’elle se produit à chaque snapshot, donc tous les jours, voire plusieurs fois par jour).

    « Cadeau bonus », quand on fait un snapshot sur un volume un tant soit peu sollicité en écriture, les performances (en lecture et écriture) sont sévèrement affectées pendant plusieurs minutes (jusqu’à un bon quart d’heure sur un MySQL) après le snapshot; au point qu’on a « interdit » à notre système de prendre des snapshots sur les maîtres MySQL, et qu’on prend les snapshots uniquement sur les esclaves.

    2. DRBD

    Comme tu le soulignes, la bande passante réseau est limitée (à moins de prendre les instances les plus puissantes). On l’a constaté sur des instances servant du contenu depuis EBS (j’ai en mémoire un cas de redimensionnement d’images à la volée sur des m2.2xlarge). Dans notre cas, les performances étaient largement en deça de ce qu’on pouvait attendre, et faire un cache des données sur un volume éphémère a grandement aidé. Du coup, je me demande : est-ce que le DRBD est recommandé sur ces « petites » instances, ou bien est-ce qu’il faut le réserver à celles ayant des interfaces 10G? (Je mets « petites » entre guillemets, parce qu’on parle quand même d’instances avec 32 Go de RAM, et qui coûtent plus de $500/mois!)

    De plus, si la latence au sein d’une AZ est faible (de l’ordre de la milliseconde), la latence entre AZ est nettement plus élevée (4-5ms RTT) ; est-ce que l’impact sur les performances DRBD est acceptable ?

    3. Réattribution des EIP

    Nous avons décidé de ne pas utiliser les adresses IP élastiques pour assurer la haute dispo, pour une raison simple : lors des grosses pannes (affectant toute une AZ, ou même une partie d’une AZ), les points d’entrée API sont pris d’assauts par les gens qui ont besoin de reprovisionner des instances … et cela peut mettre longtemps (plusieurs minutes, voire, lors des grosses pannes de l’été 2012, plusieurs heures) avant de pouvoir réassocier une adresse IP élastique. Est-ce que le problème a été évoqué ?

    Merci !

  • Bonjour !

    Ma dernière expérience sur EC2 avec de réelles problématiques de charge (un jeu Facebook dans le top 10) date aussi d’il y a quelques années (5 en fait maintenant), je n’ai pas eu depuis l’occasion de bencher autant l’infrastructure AWS, mais ce que je peux dire :

    1/
    Dans le cas précité, nous avions la possibilité d’arrêter le service quelques secondes du fait de la criticité qui le permettait et des courbes de charge qui montraient un creux tout à fait propice à un arrêt/démarrage du service. En revanche j’ai déjà travaillé sur un autre projet (mais avec nettement moins de charge) avec les snapshots LVM2 (snapshots différentiels => seule les modifications sont inscrites). Serait-il possible d’utiliser un snaphot transitoire pendant la période de snapshot EBS ? Sur les esclaves ? Sur le maître ? C’est une idée non testée sur une grosse charge… Donc je ne sais pas ce que cela peut donner.

    2/
    A l’époque il n’existait pas de notions de « EBS Optimized » pour les instances EC2, ni de « Provisioned IOPS » pour les volumes EBS. J’ai effectivement galéré au niveau de la latence EC2 – EBS (ratio écriture/lecture de 1:1… => latence = boom!), même avec RAID0 & Co. Amazon a assuré (cette année encore) qu’ils ont fait des améliorations sur ce sujet, notamment via les options précitées. Les disques éphémères avaient été une solution à l’époque pour lisser les performances et également l’utilisation/optimisation du cache au niveau de nos bases de données (MySQL & Redis) et de la synchro sur disque. Tout mis bout à bout on y arrivait, mais ce n’était pas simple.

    Actuellement avec des instances « EBS Optimized » qui autorisent du 1000 Mbps (1Gbps) + les volumes EBS derrière avec des « Provisioned IOPS », je pense qu’il y a quelque chose à faire de mieux qu’auparavant. Si on a besoin d’un NAS unifié dans le cadre d’un projet suffisamment important, je préférerais utiliser une instance dans un cluster 10Gb et la rentabiliser/mutualiser.

    Maintenant pour l’utilisation de DRBD inter-AZs, je n’ai pas testé. C’est une bonne pratique d’architecture qui a été proposée lors de la session. En fonction des projets auxquels je suis confrontés, la disponibilité inter-AZs n’est pas toujours ce que je préconise/mets en place : je préfère, quand le cas le permet (en fonction de l’expression du besoin en termes de RTO, RPO, budget, …), rester sur du mono-AZ avec un PRA très réactif basé sur l’automatisation (AMIs socle up-to-date, Puppet, Capistrano, Docker, Shell, …). Donc je reste dans une AZ et me soucie moins de la latence.

    3/
    Le problème n’a pas été évoqué.

    Si je ne me trompe pas, le cas que tu cites est un problème qui s’est produit au niveau du backend d’une AZ (sorte de partitionnement réseau au niveau des EBS) qui a engendré un engorgement au niveau des endpoints de la région qui a fait que la pile de requêtes a mis un temps certain à revenir à la normale.

    On avait commencé par utiliser un HAProxy avec une EIP, mais l’instance en front a montré ses limites en termes de bande passante. Comme nous avions une courbe de charge avec une évolution qui n’était pas en créneau (type test de charge abrupte), cela nous a permis d’utiliser un ELB en front avec plusieurs serveurs web directement derrière : donc plus d’EIP, mais un alias (qui posait un petit problème pour le A record du DNS avant qu’AWS ne mette à dispo les « ALIAS to A » et « ALIAS to AAAA » dans Route 53 pour faire pointer le root domain sur les ELBs ;ob).

  • Bonjour!

    I’m sorry but that is about the limit of my French :)

    This post came up in my Google alerts, and I wanted to ask if an overview of our part of the session would be helpful for you?

    I put a blog post together with the slides from the event, giving more insight to Zadara’s NAS-as-Service offering:
    http://blog.zadarastorage.com/2013/11/nfs-cifs-nas-cloud-options-in-aws..html
    Maybe our service can address some of the obstacles mentioned comments above.

    I hope it’s helpful!
    Feel reach out if you have any questions.

    Merci et bonne soirée!

    Noam Shendar, Zadara Storage

Répondre

 

 

 

Vous pouvez utiliser ces balises HTML

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>