Microsoft SQL Server sur Amazon Web Services

Transcript

Merci Julien, bonjour à tous, merci d'être resté entre ces deux sessions. On va donc parler de SQL Server sur AWS. Je m'appelle Julien aussi, je suis Julien Lépine, architecte solutions chez Amazon Web Services. Ça fait quatre ans et demi que je suis chez Amazon Web Services et mon rôle est d'être Solutions Architect spécialiste Microsoft. Donc toutes les questions que les clients et les partenaires d'AWS peuvent avoir sur l'écosystème Microsoft, habituellement, elles reviennent vers moi. Comme disait Julien, on va parler de SQL Server sur AWS aujourd'hui. N'hésitez pas à poser toutes les questions sur le reste de la plateforme. Je fais du SQL Server, mais je fais aussi tout le reste de la plateforme Microsoft sur AWS. D'un point de vue logistique, comment ça va se passer ? Assez simplement, on va avoir une présentation qui va prendre à peu près 45 minutes et on va essayer de se garder 15 minutes de Q&A. Posez les questions pendant la présentation ou après, n'hésitez pas. Et bien entendu, les slides seront mis à disposition pour le téléchargement sous forme PDF. Hugo s'occupe de tout ça. Qu'est-ce qu'on va faire et de quoi on va parler pendant ce webinaire ? On va commencer par parler de l'architecture du SQL Server et comment architecturer de manière efficace des plateformes SQL Server sur AWS. Ensuite, on va parler un peu des services managés. Je ne vais pas aller en profondeur dessus, puisque Julien vient de le faire avant moi. Donc, on parlera bien entendu d'Amazon RDS pour SQL Server. On va parler de la migration de données encore une fois et surtout de comment choisir le modèle le plus efficace pour votre environnement, que ce soit de partir d'un modèle Amazon RDS ou plutôt un modèle Amazon EC2 avec SQL Server. Quand on parle d'architecture, on a un programme chez Amazon Services qui a été conçu à partir des retours des Solutions Architects de toutes les expériences que nous avons eues avec nos clients, depuis plus de dix ans d'expérience avec nos clients maintenant, sur lequel on a identifié cinq piliers fondamentaux de la plateforme et qui doivent être, on espère, les piliers les plus importants pour construire une plateforme qui sera sécurisée, fiable, performante, optimale d'un point de vue budgétaire et facile à opérer. Et quand on va décrire des plateformes et des architectures de référence, on essaie toujours de se rapporter à ces cinq piliers. Ce framework que nous avons créé s'appelle le Well-Architected Framework, qui est disponible en ligne, que vous pouvez télécharger. On va essayer de voir comment architecturer une plateforme SQL Server au travers de ces cinq piliers pour s'assurer que votre plateforme sera la plus efficace possible pour vous. Le premier pilier, c'est la sécurité. Quand on parle de sécurité, on peut parler de sécurité à plusieurs niveaux. Le premier niveau, c'est le niveau réseau. C'est le premier point d'entrée avec la plateforme AWS. Julien vous l'a déjà présenté dans des webinars et même fait un dive deep sur le VPC. Amazon VPC, Virtual Private Cloud, vous donne la possibilité d'avoir un environnement réseau complètement isolé dans lequel vous allez lancer vos applications. Vous pouvez contrôler les sous-réseaux, les masques de sous-réseaux, vous pouvez contrôler les zones de disponibilité, ce qui vous permet d'avoir une plateforme hautement disponible et complètement sécurisée. En plus, vous pouvez contrôler les tables de routage et bien entendu le network ACL, donc toutes les fonctionnalités réseau que vous avez l'habitude de déployer chez vous dans vos infrastructures en termes de firewalling et en termes de gestion des sous-réseaux et des routages, vous pouvez les étendre sur AWS pour avoir cette plateforme sécurisée. En plus sur AWS, on a cette notion de Security Group. Quand on prend un VPC, on est sur de la sécurité périmétrique. Je vais avoir la possibilité d'avoir des murs très forts autour de ma citadelle. Le Security Group, c'est vraiment la possibilité d'avoir un mur autour de chacune des machines qui va être en train d'être exécutée sur AWS. Vous pouvez gérer les trafics entrants ou sortants des instances et des bases de données bien entendu par bloc d'IP ou depuis un autre security group. Ça vous donne un modèle de sécurité extrêmement flexible. Pouvoir dire en une règle que toutes mes machines web vont pouvoir accéder à ma base de données sur le port 1433 parce que je fais du SQL Server. C'est un élément de configuration ou un appel API dans les security group. Et si jamais il y a des nouvelles machines web qui viennent, elles auront automatiquement accès aux bases de données. Si elles n'auront plus accès aux bases de données, c'est très facile et très simple de pouvoir mettre ça en place. Et finalement, quand on fait de la sécurité, un des points clés c'est aussi l'auditabilité. Comment est-ce que je suis sûr de savoir que d'un point de vue réseau, il n'y a pas quelque chose qui se passe que je n'avais pas prévu ? Et donc Amazon VPC Flowlogs, qui vient encore avec les fonctionnalités d'Amazon VPC, vous permet d'avoir cette visibilité. Quand on va un peu plus loin, un security group c'est assez simple. Je vais créer un groupe de sécurité, je vais pouvoir le nommer, il aura un ID, il aura son nom, et je vais avoir la possibilité de créer des règles en entrée et en sortie. Là en l'occurrence, j'ai typiquement le port DNS qui est ouvert. Pour du SQL Server, on va retrouver typiquement les ports 1433 qui permettent de faire de la connectivité SQL Server en mode TCP. En plus de ces éléments, la partie auditabilité est très importante. Amazon VPC vous permet au niveau de chaque sous-réseau d'activer ce qu'on appelle les VPC Flow Logs. Et ces Flow Logs, vous les aurez dans un autre service qui s'appelle Amazon CloudWatch Logs, dans lesquels vous pouvez voir en quasi temps réel tous les flux réseaux qui viennent sur votre plateforme. Alors, je ne sais pas vous, mais moi je ne suis pas très bon à la lecture de NetFlow au quotidien, ce n'est pas ma tasse de thé. Donc ce qu'on a beaucoup mis en place, et ce que beaucoup de nos clients font, c'est utiliser des plateformes un peu plus importantes, un petit peu plus élevée pour lire ces logs. Typiquement, une des plateformes qui est très utilisée, c'est Elasticsearch. Elasticsearch vous donne la possibilité d'intégrer de larges volumes de données. Et en utilisant l'outil Kibana, qui est mis à disposition avec la plupart des distributions Elasticsearch, vous avez la possibilité de créer des dashboards. Ce dashboard va vous donner la possibilité de filtrer par carte réseau ou pour l'ensemble des flux réseau, quels sont les ports en entrée, quels sont les ports en sortie, très important quand vous avez une base de données pour savoir exactement ce qui est le comportement de cette base de données est un comportement que vous voulez avoir ou s'il y a un certain nombre de points qui sont des points non prévus et dans ce cas-là, vous avez la capacité de réagir très rapidement. Kibana fait de l'alerting et énormément de choses. Plutôt que de devoir monter un Elasticsearch et un Kibana et gérer tous ces éléments, plus l'intégration, on a des modèles prêts à l'emploi qui vont vous permettre de prendre les logs de vos VPC et les envoyer vers un service qui s'appelle Amazon Elasticsearch, qui est un modèle Elasticsearch complètement managé par Amazon. Donc là, on est un peu sorti du monde SQL Server, mais vraiment, ce point sur la sécurité réseau est critique pour vos bases de données, parce que vos bases de données vont stocker vos données les plus confidentielles et les plus sécurisées. Maintenant qu'on a mis en place la sécurité autour du réseau, on va vouloir avoir la possibilité de savoir qui a le droit de toucher à mes instances, qui peut créer une nouvelle machine, qui peut supprimer une nouvelle machine, qui peut lancer un snapshot comme Julien l'a présenté, ou qui peut changer les configurations réseau. Tous ces éléments-là, on les a dans AWS IAM, Identity and Access Management, qui vous donne la possibilité d'utiliser vos credentials Active Directory on-premises ou des utilisateurs que vous allez créer sur la plateforme directement, de l'authentification multiple facteurs et beaucoup d'autres éléments. Vous avez vraiment encore une fois une grande flexibilité sur ce que vous pouvez faire au niveau de la plateforme. Et vu qu'on a la possibilité de modifier votre environnement, typiquement on a la possibilité de modifier la configuration du réseau comme on l'avait vu juste avant, on va remettre une couche d'auditabilité à ces éléments-là. AWS CloudTrail vous donne la possibilité d'avoir une visibilité sur toutes les actions faites par chacun de vos utilisateurs, que ce soit une authentification avec des credentials Active Directory, une modification d'instance, une modification de base de données. Et on va avoir une console autour de CloudTrail qui vous donne une visibilité complète sur tout ce qui se passe. Donc là on voit que moi Julien, je me suis connecté à la console à travers un service qui s'appelle ds.amazonaws.com. C'est le service avec AWS Directory Service pour Active Directory. J'ai utilisé mon utilisateur Active Directory pour accéder à la console. Chaque événement est donc tracé, tagué, catégorisé pour que vous puissiez avoir une auditabilité complète. À partir de maintenant, vous avez un réseau qui est complètement géré et toutes les modifications de ce réseau sont encore une fois complètement sécurisées. Ce qu'on va vouloir, c'est s'assurer que les personnes qui accèdent à la base de données, soient seulement les personnes qui sont intéressantes pour accéder à la base de données. On va d'abord commencer par gérer le contrôle, c'est-à-dire s'assurer qu'on ne donne pas les droits système-administrateur à tous nos utilisateurs, malheureusement une pratique que l'on voit régulièrement dans le monde SQL Server, d'autres bases de données d'ailleurs, mais bien s'assurer qu'on va créer des utilisateurs, ou en tout cas donner des droits aux utilisateurs, de manière limitée. Les limiter sur les actions qu'ils peuvent effectivement effectuer et les tables sur lesquelles ils peuvent les effectuer. Et vu qu'on est dans le monde Windows, ce qu'on va vraiment vouloir faire, c'est éviter d'utiliser l'authentification SQL Server, qui est une authentification locale stockée en local sur la machine SQL Server, mais plutôt utiliser l'authentification intégrée Windows, et donc utiliser vos utilisateurs Active Directory que vous avez définis, qui sont gérés, quand vous avez un nouvel employé qui rentre dans votre entreprise par exemple, il va avoir un compte qui sera créé dans Active Directory. Quand il va quitter l'entreprise, ce compte va être désactivé. Si vous intégrez vos bases de données avec ces process-là, automatiquement tous les accès aux applications et aux bases de données de ces utilisateurs seront révoqués ou activés. Donc vraiment très facile à mettre en place et SQL Server a vraiment ce modèle qui est extrêmement pratique pour toutes les utilisations desktop ou pour énormément d'autres utilisations où vous voulez avoir une granularité extrêmement fine sur les droits de base de données. Ensuite, on va parler de chiffrement. Une fois qu'on s'est assuré que le réseau était bon, qu'on avait le contrôle sur les API et qu'on avait les droits sur la base de données qui étaient bien restreints, on va avoir la possibilité de se dire que d'un point de vue conformité ou sécurité, on va vouloir chiffrer l'ensemble de nos données. Et donc on a deux modèles de chiffrement qui sont les modèles principaux. Le premier, c'est le chiffrement des données au repos. Toutes les données qui sont stockées sur la base de données vont être automatiquement chiffrées. Et le deuxième, c'est la possibilité d'avoir du chiffrement en transit. Donc toutes les connexions à la base de données, on va pouvoir forcer le chiffrement. Pour la protection des données au repos, Julien en a parlé dans la partie sur Amazon RDS, on a la possibilité d'utiliser Amazon KMS, Key Manager Service. Ce service là est un service qui va s'assurer que tous les blocs de données sont chiffrés. Il n'y a aucune modification à faire au niveau de la base de données ou de vos applicatifs. Ces éléments là sont gérés au niveau de l'hyperviseur et des volumes de stockage. Donc toutes les données sont chiffrées avant d'être stockées. Après, on a d'autres modèles tels que TDE, Transparent Data Encryption, qui est supporté par Microsoft SQL Server, où là vous allez pouvoir intégrer votre base de données avec un gestionnaire de certificat et ce gestionnaire de certificat va donner le droit de lire la base de données ou à donner le droit au moteur de base de données d'accéder aux données. Et là c'est bien le moteur de base de données qui lui-même va faire des opérations de chiffrement avant de les stocker sur disque. Donc on est même une étape avant, au lieu que ce soit l'hyperviseur qui va faire le chiffrement, l'applicatif SQL Server va faire le chiffrement. Point intéressant, vous avez encore une fois aucune modification à faire, c'est de la configuration de SQL Server et non de la modification d'applicatif. Et après, on a aussi la possibilité d'aller au niveau des colonnes et au niveau de l'applicatif pour se dire certains éléments de ma base de données devront être chiffrés soit par le moteur, soit même par mon application. Et donc vous pouvez intégrer vos applications avec AWS KMS pour que les données soient chiffrées avant même d'être envoyées dans la base de données. Et donc la base de données, tout ce qu'elle aura, c'est un blob, un form, complètement chiffré et donc vous aurez une sécurité encore supérieure de vos données. Pour la partie stockage de chiffrement des données en transit, SQL Server, vous pouvez le configurer pour qu'il utilise un certificat et il utilise les fonctionnalités SSL pour avoir un chiffrement efficace. Donc vraiment, ce chiffrement, c'est un des points clés et Werner Vogels, notre CTO, le pousse vraiment. Le chiffrement, c'est presque plus une option. Vous devez pouvoir chiffrer l'ensemble de vos environnements et faire du chiffrement avec Amazon KMS est complètement gratuit. Donc n'hésitez pas à regarder ses fonctionnalités pour toutes vos bases de données. C'est toujours une bonne pratique d'être plus sécurisé. Maintenant, on va parler de fiabilité. Donc maintenant, on a une base de données sécurisée. Le premier élément de la sécurité quand on est en France, c'est disponibilité, intégrité, confidentialité et traçabilité. Les trois derniers points, intégrité, confidentialité et traçabilité, on les a avec les options de sécurité dont on a parlé maintenant. La disponibilité, donc la haute disponibilité en l'occurrence, c'est vraiment un élément tellement critique qu'on en a fait un pilier à part. Et quand on voit avec MySQL ou avec Aurora, tel qu'en a parlé Julien, globalement, ce qu'on va vouloir, c'est avoir un cluster de bases de données. On va vouloir avoir une base de données active, une base de données passive, une réplication synchronisée entre les deux et un modèle de cluster entre les deux qui nous permettent de dire si ma base maîtresse tombe en panne, je veux que ma base secondaire devienne le nouveau master et soit capable de le servir. Il y a eu un certain nombre de questions sur la possibilité d'avoir des bases active active donc multi master. Ce n'est pas un modèle qui est supporté par SQL Server. Ce n'est pas un modèle qu'on va pouvoir retrouver dans Amazon RDS. Mais on est bien sur des modèles actifs, passifs. Donc soit passifs complètement éteints pour faire de la réplication synchrone, soit passifs en lecture seule avec de la réplication asynchrone et on y reviendra après. Le modèle de déploiement reste un modèle de déploiement très AWS. J'ai une région AWS, donc je vais pouvoir typiquement, si je suis en France, choisir très bientôt la région Paris ou alors choisir la région Francfort, choisir la région Londres ou la région de Dublin pour déployer ma base de données. Je vais avoir au sein de cette région un VPC que je vais créer pour configurer et complètement gérer mon environnement réseau. Et au sein de ce VPC, je vais utiliser les différentes zones de disponibilité de ma région et créer des sous-réseaux au sein de ces zones de disponibilité. Ça me donne la possibilité d'avoir une base de données qui va être sur plusieurs zones de disponibilité, donc plusieurs ensembles de data centers complètement isolés les uns des autres. Tout en ayant une latence de réplication, donc on va faire de la réplication synchrone, parce que ma latence réseau est de l'ordre de 1 à 2 millisecondes. Donc on est vraiment sur de la haute performance au niveau réseau, tout en ayant vraiment cette extrêmement haute disponibilité. Donc ça c'est le but de ce qu'on va vouloir avoir. Mais comment l'architecturer réellement avec Microsoft SQL Server ? On va avoir plusieurs modèles. Le premier modèle que l'on va pouvoir trouver, c'est un modèle que Microsoft appelle le failover cluster instances. On va avoir deux machines, un réplica primaire et un réplica secondaire. Ces deux machines vont faire partie d'un cluster. Ce cluster, on le crée avec un rôle Windows qu'on appelle le Windows Server Failover Clustering. Ce modèle-là vous donne la possibilité de dire je vais avoir deux machines qui vont marcher en termes de cluster et si jamais un élément venait à être indisponible, la machine secondaire deviendrait la machine à utiliser. Pour pouvoir utiliser le modèle failover cluster instances, il va falloir utiliser un modèle que l'on appelle le shared storage, donc un stockage partagé entre les différentes instances. Pour tous les utilisateurs de cloud et pour tous ceux qui ont vraiment travaillé, vous savez qu'on n'a pas une zone de disponibilité qui soit partout. Quand on a du stockage, il est dans une zone de disponibilité. Puisqu'on va stocker sur des volumes Amazon EBS. Et donc, pour avoir ce stockage partagé que l'on veut être hautement disponible, on va devoir utiliser des solutions partenaires, des partenaires tels que StorNAS, NetApp, Syos ou d'autres, qui ont construit une solution logicielle qui va utiliser plusieurs volumes EBS dans plusieurs zones de disponibilité. Donc on va encore une fois récupérer cette haute disponibilité et cette indépendance entre les niveaux de stockage, et eux vont gérer la réplication au niveau des blocs de stockage entre ces deux volumes. Et ils vont aussi proposer à SQL Server une adresse IP qui sera une adresse IP flottante qui existe sur plusieurs zones de disponibilité. C'est vraiment une fonctionnalité très spéciale de ces logiciels-là parce que c'est encore une fois pas une fonctionnalité par défaut que l'on peut avoir sur la plateforme et qui va permettre au cluster Windows de croire qu'il est en train de parler à un point d'entrée qui lui-même sera partagé sur plusieurs zones de disponibilité. Donc si vous voulez utiliser le modèle failover cluster instance, qui a un certain nombre d'intérêts très importants pour SQL Server, le premier en termes de licensing, ça vous permet d'avoir de la réplication synchrone, c'est même pas de la réplication finalement, c'est de la haute disponibilité synchrone entre deux bases de données sur deux zones de disponibilité, en utilisant l'addition standard de SQL Server. Ça vous permet aussi d'utiliser sur les versions avant Windows Server 2016 et SQL Server 2016 des modèles tels que le Microsoft Distributed Transaction Coordinator qui vous permet d'avoir des transactions sur plusieurs bases de données ou sur plusieurs serveurs. Donc il y a un certain nombre de points d'usage qui sont intéressants avec ce stockage partagé. Néanmoins, on le voit bien ici, on a un élément qui est hors des zones de disponibilité. Ça ne va pas être le modèle recommandé par Amazon sur le développement d'une base de données hautement disponible. Le modèle que Amazon va recommander, c'est un modèle sur lequel on va avoir du stockage sur chacune des bases de données qui sera complètement isolé. Et ces machines, sur deux zones de disponibilité, vont avoir une réplication qui va être mise en place. Cette réplication sera bien entendu synchrone pour être dans un mode de haute disponibilité. Il y a une question qui a été posée tout à l'heure à Julien, que j'ai trouvée très intéressante. Julien n'a pas le temps d'y répondre malheureusement sur comment évite-t-on d'avoir un modèle enfin d'avoir le syndrome du split brain scenario quand on a une machine qui tombe en panne ou quand on a plutôt le réseau qui va devenir indisponible. Donc premier élément, le réseau devient très peu indisponible sur AWS, on est sur un réseau hautement disponible et complètement virtualisé donc les interruptions réseau entre plusieurs machines sont d'une extrêmement rare. Néanmoins, c'est quelque chose qui peut arriver. Always On Availability Groups et mirroring se basent encore une fois sur la technologie Windows Server Failover Clustering. Ce modèle, on peut le déployer sur plusieurs zones de disponibilité en utilisant ce qu'on appelle un serveur witness. Ce serveur witness va servir à savoir qui est le leader. Un cas d'usage simple, j'ai une base de données qui fonctionne sur mon réplica primaire, qui répliqué en synchrone sur mon réplica secondaire, j'ai une interruption au réseau entre mon réplica primaire et mon réplica secondaire. Les deux machines ne peuvent donc plus discuter l'une avec l'autre. Et la décision du split-brain qui peut arriver si on n'a pas cette élection du maire ou ce witness, c'est de se dire, le secondaire se dit, le primaire n'est plus disponible, donc je deviens un primaire, et le primaire se dit, moi je suis toujours là, donc je continue à servir. Et dans ce cas-là, les transactions viennent sur une machine ou sur l'autre, et on a plus la cohérence des données entre les deux éléments. Avec cette notion de witness, on va avoir une troisième machine, ici déployée dans une troisième zone de disponibilité lorsque c'est possible, qui elle va être capable de faire l'arbitre. Elle va pouvoir dire aux réplicas primaires « Non, c'est bon, tu es toujours là, tu continues à marcher », et elle va être capable de parler aux réplicas secondaires en lui disant « Le réplicas primaire est toujours là, ne deviens pas maître, c'est bien une interruption réseau ». Et donc, le système va continuer à fonctionner. Donc, c'est vraiment le modèle le plus efficace pour avoir de la haute disponibilité au niveau des bases de données. Deux instances dans deux zones de disponibilité avec un stockage local et finalement, un nœud qui va permettre de faire cette élection du maître et donc maintenir cette cohérence des données. Maintenant, on a certaines régions sur lesquelles on n'a que deux zones de disponibilité. Donc, une question que j'ai fréquemment de la part de mes clients, c'est comment est-ce que je vais être d'utiliser ce modèle d'élection du maître alors que je n'ai que deux zones de disponibilité. On va pouvoir le faire en ayant un réplica primaire et un secondaire dans deux zones de disponibilité différentes encore une fois et de mettre le witness, donc le nœud d'élection, dans la même zone de disponibilité que le primaire. En fonction des designs, certains vont vouloir le mettre dans la même zone de disponibilité que le secondaire. Ma recommandation est plutôt de le mettre dans la zone de disponibilité du primaire, pour que si jamais il y a une interruption réseau entre les deux zones de disponibilité, on n'ait pas un failover automatique juste à cause de ça. Le primaire étant la base par défaut active, si j'ai une interruption réseau, le secondaire ne sera plus capable de parler ni au primaire ni au witness, et donc restera secondaire, et le primaire lui sera capable de parler au witness et donc restera primaire. Et on évite comme ça d'avoir des failover automatiques trop fréquents. Donc vous aurez les slides, ça fait vraiment partie des architectures de référence sur avoir de la haute disponibilité sur SQL Server. Mais SQL Server propose un petit peu plus de fonctionnalités. Quand on va utiliser des fonctionnalités telles que le log shipping ou la réplication transactionnelle, si on est sur des vieilles versions du SQL Server, mais même plutôt si on utilise Always On Availability Groups, on a la possibilité d'avoir des modèles un peu plus efficaces. On va avoir encore une fois un primaire et un secondaire pour avoir ma haute disponibilité donc toujours une réplication potentiellement j'ai même un witness qui est toujours dans ma troisième zone de disponibilité pour avoir mon élection du maître et en plus de ces éléments là je vais avoir la possibilité de lancer une nouvelle base de données qui sera encore un secondaire sauf que ce secondaire je vais le configurer en réplication asynchrone. L'intérêt de l'avoir en réplication asynchrone, c'est que c'est une base de données qui va devenir active. Et sur cette base de données active, elle sera en lecture seule. Je vais pouvoir lancer typiquement mes applications de reporting. Et donc si vous avez des sites web à fort volume, j'ai travaillé dans plusieurs entreprises qui avaient des sites web à fort volume, c'est typiquement un modèle dans lequel vous pouvez avoir jusqu'à 6 read réplicas sur une base de données pour avoir ce load balancing au niveau des catalogues frontaux par exemple. Ou pour avoir plus de disponibilité, enfin plus de temps de réponse plus faible sur vos lectures, sur la base de données. Donc c'est un modèle très important et que vous allez pouvoir étendre sur beaucoup d'autres modèles. Et un des modèles dans lequel on va beaucoup travailler, c'est aussi se dire, et si jamais je voulais avoir un plan de disponibilité au-delà de la région ? Eh bien on va pouvoir trouver la même architecture avec une zone de disponibilité pour mon primaire, une zone de disponibilité pour sont modèles en réplication synchrone toujours exactement le même modèle et potentiellement une réplication à travers un VPN sur une deuxième région AWS. Et donc là j'ai la possibilité d'avoir des backups dans une deuxième région et d'avoir une autre disponibilité complète. Là je n'ai non seulement la disponibilité de deux zones de disponibilité dans une région mais là j'ai même la possibilité de faire des plans de reprise d'activité sur une deuxième région. Encore une fois, on va avoir notre troisième serveur pour le witness qui sera dans la région primaire. On va vraiment avoir la possibilité d'étendre. Et voire même, une question qu'on a régulièrement de la part de nos clients, comment est-ce que je fais pour avoir une sauvegarde sur site pour des cas de retour arrière ou autre ? Cette fonctionnalité d'avoir un read replica sur lequel on va pouvoir exécuter des backups, on va aussi pouvoir le déployer chez vous. Et c'est typiquement le genre de cas dans lesquels on va déployer une fonctionnalité tel qu'AWS Direct Connect qui vous donne une connectivité réseau directe, fibre optique entre vos infrastructures et la plateforme AWS. Donc vos bases de données seront hautement disponibles dans le cloud, extrêmement sécurisées et très performantes et en plus vous garderez une sauvegarde locale ou une sauvegarde sur une autre région en cas de besoin. Donc voilà, ça c'était les éléments sur la haute disponibilité de SQL Server. Maintenant on va se poser des questions de performance. Comment est-ce que je suis capable d'optimiser la performance de mes bases de données sur SQL Server quand je le fais tourner chez Amazon ? Le premier, ça va être de choisir le bon type d'instance. Chaque type d'instance, et on a plus de 50 types d'instances différentes disponibles maintenant chez Amazon Web Services, va vous fournir trois capacités qui sont des capacités importantes. Le premier, c'est la possibilité de choisir le nombre de VCPs que vous allez avoir. Donc les vCPU sur les nouvelles générations, ce sont des coeurs physiques de processeurs Intel ou un hyperthread qui lui est associé. Donc quand vous avez une machine telle qu'une R3 8X Large, vous allez avoir la possibilité d'utiliser 32 vCPU pour vos plateformes. En plus de cette gestion du CPU qui est très importante pour les bases de données, surtout pour les bases de données qui vont avoir beaucoup de calculs bas, chez les choses du genre, où c'est assez utilisé en CPU, ce qu'on voit beaucoup, c'est que les bases de données, elles ont besoin d'avoir beaucoup de RAM. Et donc, les catégories telles que les C3, enfin les C4, vont avoir deux fois moins de RAM que les M4, et les M4 ont les mêmes deux fois moins de RAM que les R4. Si on le prend dans l'autre sens, en fonction du besoin d'usage de vos bases de données, pour un même nombre de VCPU, si je prends une C4 8X Large, je vais avoir 32 VCPU mais par contre je vais pas avoir beaucoup de RAM, je vais avoir sur une 8X Large 32 giga de RAM. Si je vais sur une M4, je vais avoir beaucoup plus de mémoire. Si je vais sur une R4, je vais avoir encore plus de mémoire qui me donne la possibilité d'avoir jusqu'à 244 giga de RAM. Et en parallèle de ça, plus vous avez des instances qui sont grandes, plus vous allez avoir une partition du réseau qui va vous être dédiée qui va être importante. Et donc on peut avoir des machines telles que typiquement les X1 qui vont vous proposer 128 vCPU, 2 gigas de RAM en utilisation directe et du réseau 20 gigabits par seconde en sortie. Donc si vous avez des bases de données qui ont besoin d'extrêmement de performance que ce soit en termes de vCPU, de mémoire ou de réseau, vous avez la possibilité de choisir dans le catalogue Amazon les machines qui vont être intéressantes pour vous. Maintenant on était vraiment sur la machine. Ensuite on va pouvoir optimiser le stockage. Rien que sur les machines que l'on va pouvoir choisir, on l'a dit, vous pouvez choisir la bande passante réseau que vous allez avoir en sortie. Et par défaut une machine Amazon va partager sa bande passante entre les disques EBS, donc le stockage qui va être utilisé pour stocker vos données, et le réseau qui va être utilisé pour servir les données. Et donc pour des bases de données qui vont avoir beaucoup de transactions à traiter, on va se retrouver sur un modèle parfois d'étranglement des capacités réseau et donc Amazon EC2 propose une fonctionnalité qu'on appelle EBS Optimized où vos instances vont avoir deux cartes réseau disponibles, la première une carte réseau qui va servir à servir le trafic pour vos utilisateurs et la deuxième une carte réseau qui va être dédiée à la bande passante vers vos stockages. Et donc vous pouvez avoir des bases de données qui du coup vont avoir beaucoup plus de performance juste en utilisant cette fonctionnalité là. Si vous êtes sur les dernières générations d'instances telles que les M4 ou les R4, par défaut les machines sont EBS Optimized. Donc il n'y a aucune question à se poser, ça devient un bénéfice de la plateforme. En plus, sur les bases de données, on va vous donner, sur les machines, en fonction des générations et du type de machines, vous pouvez avoir du stockage local. Ce stockage local va être sur soit du disque dur, soit du SSD, ou même pour les dernières générations de machines, telles que les i3, du Non-Volatile Memory Express, donc du NVMe, qui vous donne des temps de latence en termes d'accès au stockage qui sont extrêmement faibles, et des vitesses de lecture-écriture qui sont extrêmement puissantes. Par contre, c'est du stockage qu'on appelle éphémère. Pour les bases de données critiques, comme celles utilisées pour les ERP, Provisioned IOPS est idéal. Il existe également des disques magnétiques pour des usages spécifiques, comme le stockage de backups, qui sont moins chers et optimisés pour l'écriture séquentielle. Microsoft Windows propose également des options de configuration de stockage via Storage Spaces, vous permettant de configurer des niveaux de RAID et de spanning de disques. Vous pouvez créer des volumes EBS en back-end pour des configurations similaires à celles que vous avez sur site. Par exemple, vous pouvez configurer un grand volume de plusieurs disques de 16 To chacun pour des bases de données volumineuses, ou utiliser du mirroring pour améliorer les performances en lecture. L'optimisation du stockage est cruciale pour les bases de données. Changer le type de stockage avec Amazon EBS peut se faire en temps réel, mais prendra plusieurs minutes, voire des dizaines de minutes pour des disques de 16 To. Il est donc important d'avoir une bonne vision des performances attendues et d'architecturer de manière efficace. D'autres optimisations au niveau système incluent la configuration de l'affinité processeur pour l'optimisation de SQL Server, la configuration du swap et du sizing sous Windows. Julien a fait un deep dive sur l'optimisation du kernel sous Linux, et les mêmes options sont disponibles sous Microsoft Windows. Au niveau du moteur de base de données, vous pouvez optimiser en stockant les bases de données temporaires sur des disques SSD locaux, configurer le nombre de threads en fonction du nombre de vCPU pour éviter la contention des transactions, et ajuster la croissance des volumes. Vous avez également accès à toutes les fonctionnalités d'un DBA pour optimiser les index, les procédures stockées, et les triggers. Un exemple de client, HES, un grand conglomérat énergétique aux États-Unis, a migré plusieurs centaines de serveurs et de teraoctets de données sur AWS. Ils ont pu migrer jusqu'à 100 serveurs par jour, finalisant la migration en moins de 6 mois. Un défi clé était de vendre une sous-entité tout en isolant son système d'information. Grâce à AWS, la transition du système d'information à l'acquéreur a pris seulement 30 minutes, facilitant la vente. D'un point de vue financier, après avoir optimisé les performances, il est important de considérer le licensing et le coût. Amazon EC2 offre une grande flexibilité en termes de licence. Le modèle Licensing to Lead inclut la licence Windows et SQL Server, que vous payez à l'heure. Vous pouvez également utiliser vos licences existantes (Bring Your Own License, BYOL) si vous avez un accord avec Microsoft. Pour les clients avec des contraintes réglementaires, les dedicated hosts permettent d'utiliser vos licences Windows et SQL Server sur des infrastructures dédiées. Un modèle hybride est souvent adopté, où les bases de données back-end utilisent BYOL pour économiser sur les licences, tandis que les applications élastiques, comme les sites web, utilisent le modèle licence incluse pour bénéficier de l'élasticité. Infore, un éditeur international d'applications, a optimisé ses coûts de backup de 75% en utilisant Amazon EBS ST1 pour les backups, tout en gagnant en agilité. Pour monitorer SQL Server, Amazon CloudWatch fournit des métriques sur l'utilisation du CPU, l'IO, et d'autres indicateurs. Si vous utilisez Amazon RDS, vous avez accès à des métriques plus avancées, comme l'utilisation de la mémoire, l'espace de stockage, et le nombre de connexions. Amazon RDS offre également des fonctionnalités de haute disponibilité, des backups automatisés, et des sauvegardes de logs toutes les 5 minutes. Vous pouvez également gérer les mises à jour, changer de type d'instance, et intégrer Active Directory et Amazon VPC pour la sécurité. Lors de la création d'une base de données RDS SQL Server, vous pouvez choisir le réseau et la sécurité, en rejoignant un domaine Active Directory existant. Vous pouvez également configurer des utilisateurs depuis un domaine externe via des trusts, héritant ainsi de la sécurité Active Directory existante. La migration des données vers Amazon RDS peut se faire via le Database Migration Service, qui fait un snapshot de la base de données source, la restaure sur la destination, et met en place une réplication en temps réel. Vous pouvez également utiliser des backups natifs, le Database Publishing Wizard, SQL CMD, et BCP pour des migrations plus simples. En résumé, Amazon RDS est recommandé par défaut pour sa simplicité et sa gestion complète, mais Amazon EC2 offre plus de contrôle si nécessaire. Le choix entre RDS et EC2 dépend de vos besoins en termes de contrôle, de gestion, et de licensing. Pour commencer, créez un compte AWS et explorez les services gratuits, consultez le Well-Architected Framework, et participez aux webinaires et événements AWS pour approfondir vos connaissances. Est-il possible d'utiliser les nouvelles fonctionnalités Windows Server 2016 et Storage Replica, simplement Storage Spaces Direct, par exemple ? À date, Storage Spaces Direct est fait pour être utilisé au niveau du stockage physique des machines et pas au niveau des stockages cache. Donc non, nous ne supportons pas encore, et j'espère qu'on le supportera bientôt, les fonctionnalités telles que Storage Spaces Direct, sur lesquelles les disques de vos instances, vous pouvez les répliquer. Amazon EBS, par défaut, est déjà un modèle répliqué. Donc on n'a pas la possibilité de... Enfin, vous n'avez pas besoin finalement de mettre en place un RAID supplémentaire pour avoir de la disponibilité. Storage Spaces Direct est vraiment fait pour répliquer à ces besoins là. Ce que vous allez pouvoir faire et la deuxième limite c'est de se dire que Storage Spaces Direct est fait pour avoir deux machines la plupart du temps dans le même réseau. Là ce qu'on veut c'est avoir des machines dans deux zones de disponibilité différentes, donc des réseaux différents. Et donc on va plutôt utiliser des solutions actuellement d'architecture pour répondre telle que j'en ai parlé, Cios, SoftNAS ou NetApp pour répondre à ces besoins là. C'est quelque chose si jamais vous avez vraiment besoin n'hésitez pas à revenir vers nous, on est à l'écoute de tous les feedbacks sur ces éléments. Dans le cas de Direct Connect, question d'Arnaud, peut-on avoir le master dans le data center du client et uniquement les réplications sur AWS ? Oui tout à fait, vous allez faire porter un certain nombre de besoins en termes de disponibilité au niveau du réseau, mais Direct Connect, qui est notre solution de connectivité, est évidemment faite pour ça. Vous avez la possibilité d'avoir une connexion fibre dédiée entre vos environnements on-prem et AWS. Et donc la réplication va venir d'une base de données on-prem pour aller vers AWS. C'est un cas qu'on peut voir typiquement dans les cas de sites de vente en ligne. On a beaucoup de sites de vente en ligne qui font ça. Sur leurs premières étapes de migration, ils vont déployer les front-end web sur AWS et garder, le temps de faire les migrations, les bases de données on-premises parce que c'est les bases de données historiques qu'ils avaient, et avant de faire la migration all-in sur AWS. Avec ces éléments-là, ils vont garder les bases on-prem, mettre la réplication, et avoir les frontaux sur AWS pour servir tous leurs clients. Quel design AWS a-t-il pour la partie Data Warehouse et les différents appliances qui existent ? Sur la partie SQL Server, vous avez la possibilité d'utiliser Amazon EC2 et d'utiliser, j'en ai parlé, des machines qui sont des machines extrêmement performantes pour avoir des modèles de Data Warehouse. Mais Amazon RDS propose aussi beaucoup d'autres modèles et Amazon en tant que tel propose d'autres modèles. Donc si vous voulez faire du Data Warehousing, on a aussi des solutions telles qu'Amazon Redshift que je vous engage à regarder, qui vous donnent la possibilité de faire du Data Ware à l'échelle, et on est en train de parler d'échelle d'exa octet de données à analyser directement sur la plateforme. SQL Server propose d'autres services tels que SQL Server Integration Services, Reporting Services ou Analysis Services. Est-il prévu d'étendre RDS pour proposer ces services ? À date, Amazon RDS ne propose que le moteur de données de SQL Server. Quand vous hébergez, vous hébergez des bases de données et non pas les services d'intégration. Vous pouvez étendre cette plateforme en ayant des plateformes Amazon EC2 connectées à cette base de données qui vont elles héberger la partie analytique, la partie reporting ou la partie intégration. Vous pouvez néanmoins, enfin si vous avez vraiment besoin de les avoir directement intégrées à Amazon RDS, n'hésitez pas à revenir vers nous encore une fois, les équipes sont à l'écoute de tous les besoins que vous pourriez avoir pour y répondre. Donc, encore une fois, je n'ai pas de date de sortie ou même si ça existera, mais vraiment, si vous en avez besoin, n'hésitez pas à revenir vers nous. Question licensing. Faut-il la software assurance pour utiliser des licences SQL Server sur Amazon RDS ? Question de William. La réponse est oui. Si vous voulez utiliser des licences et faire ce qu'on appelle le License Mobility, donc utiliser vos licences on-prem sur AWS, notre recommandation, c'est effectivement d'avoir la License Mobility. Et cette License Mobility se base sur deux éléments. Il faut avoir des licences que vous avez acquises en mode volume licensing, donc acheter à travers un contrat avec Microsoft. Et en plus, avoir une software assurance qui sera active sur ces licences. Et donc, ce sont les deux conditions prérequises pour pouvoir le faire. Si vous n'avez pas ces éléments-là, on rentre dans un mode de contrat plus legacy. Et ces contrats legacy, on va pouvoir les traiter avec des plateformes telles qu'Amazon OCD Dedicated Host. Mais là, vous n'avez pas les bénéfices de management de la plateforme Amazon RDS. En termes de sécurité, quel est l'avantage du chiffrement standard uniquement, typiquement, pour certaines certifications telles que PCI ou autres ? On va avoir plusieurs intérêts du chiffrement du stockage. Le chiffrement du stockage, on va pouvoir parler typiquement d'AWS KMS. Ça vous donne la possibilité de chiffrer non seulement les bases de données, mais aussi de chiffrer les backups. Donc vous allez avoir effectivement, si vous êtes soumis à certaines réglementations telles que PCI DSS, il y a une obligation de chiffrer les données dès que vous avez des données clients nominatives ou des données de carte bancaire. Ça, oui, ça vous permet de répondre à ce besoin d'audit. Mais en plus, en termes de sécurité, vous ne chiffrez pas que seulement la base de données, mais aussi les snapshots. Donc ça vous donne une visibilité complète sur le cycle de vie de ces informations, du moment où elles sont sur une instance active sur une base de données, mais aussi sur tout ce qui va se passer derrière. Donc ma recommandation c'est de regarder ces éléments là en termes de quelles vont être les disponibilités. Alors j'ai une extrêmement longue question de la part de Benoît. RDS utilisateur actuellement le mirroring, alors que Always-On Availability Group est un peu plus efficace en termes de réplication et permet d'autres fonctionnalités. Est-ce qu'il y a des plans pour intégrer Always-On Availability Group dans l'Amazon RDS ? C'est un élément sur lequel on a beaucoup de demandes de la part de nos clients. Je ne peux pas vous donner de réponse de la part des équipes produits. À date, on ne fait que du mirroring. Mais effectivement, on le regarde très activement, ne serait-ce que parce que SQL Server 2016 est la dernière version à supporter le mirroring, les versions suivantes n'utiliseront que Always-On Availability Group. Quelles sont les tâches de maintenance qu'on doit toujours gérer ? Les index, les stats, les dbcc checks, ces éléments-là ? Exactement toutes ces tâches-là. Toutes les tâches qui sont des tâches à mettre en ce niveau du moteur de base de données, sur lequel le moteur doit effectuer quelque chose ou qui sont liés au contenu des bases de données, sont des éléments que vous allez mettre en place directement et sur lesquels nous, on n'a pas d'action. Nous, on automatise le moteur, sa configuration, son backup, sa mise en disponibilité, mais on ne touche pas à l'intérieur des bases de données. Et donc, tout ce qui est vraiment à l'intérieur du moteur de base de données, la configuration, la gestion des index, et tout ça reste vraiment à votre charge et vous allez avoir le besoin de les mettre en place. Avec Database Migration Service, est-ce qu'on peut pousser des données dans une destination contenant déjà des données de prod sans casser les réplications, sans casser les contraintes ? Database Migration Service est un service qui est fait pour faire de la migration de bases de données. Ma recommandation est toujours de partir d'une base de données qui sera une base de données vierge. Par défaut, Database Migration Service va utiliser les fonctionnalités pour dire typiquement j'ai la possibilité d'insérer des nouvelles identités dans les colonnes qui sont des colonnes avec identité ou sur des clés primaires. Donc lui va pouvoir le gérer. Par contre, il ne fait pas de contrôle préalable sur la cohérence des données. Si vous avez déjà des données qui sont dans vos bases de données de prod et qui existent avec les mêmes éléments, vous allez avoir des incohérences. Donc je vais vraiment vous recommander sur du Database Migration Service de commencer avec des bases de données vraiment neuves si possible. Sur Amazon RDS SQL Server, comment on peut changer les IOPS d'un stockage, ou changer la taille du stockage ? C'est une limitation forte qu'on a actuellement sur RDS SQL Server. Les équipes travaillent, je peux vous assurer, nuit et jour pour répondre à ces besoins-là. Il y a une nouvelle fonctionnalité qui est sortie il y a très peu sur Amazon EBS, qu'on appelle le Dynamic EBS, qui donne la possibilité de redimensionner les volumes EBS directement. J'espère et vraiment je pousse les équipes au quotidien pour que ça revienne très bientôt sur Amazon RDS. Encore une fois, je n'ai pas de date de sortie qui soit disponible. Mais voilà, on fait tout pour que ça arrive très vite pour vous. Je pense qu'on est bon au niveau des questions. Je voulais vous remercier pour toutes les questions que vous aviez pu poser. J'espère que ça vous aura plu aujourd'hui. Alors, il faut choisir un gagnant ! Encore une fois merci beaucoup, j'espère que vous revoir bientôt dans les mardis du cloud ou au Summit ou au ZooSomday. Donc encore une fois n'hésitez pas à venir à tous les événements qu'on met en place pour vous. Merci et bonne fin de journée.