Pourquoi devrions-nous construire un CDN?

Salut Habr! Dans cet article, nous allons créer notre propre CDN. Pourquoi ne pas utiliser des solutions toutes faites? Parce que le site de l'auteur est complètement statique, réalisé sur Jekyll, avec de grandes images qui doivent être données le plus rapidement possible. Le serveur ne doit pas être en cache, il doit stocker l'intégralité du site, prendre en charge HTTP / 2 et Brotli, et le même certificat doit être installé sur tous les serveurs.

Nous ferons également tout cela sur IIS exécuté sur Windows Server 2019 Core.

En bref sur la mise en œuvre

Aux nœuds finaux, nous gérerons les moyens intégrés au système d'exploitation, nous aurons besoin:

1. Active Directory
2. Dfs
3. IIS
4. Winacme
5. RSAT

Facultatif, mais recommandé:

1. Centre d'administration Windows

Sur les sites avec sites, seuls IIS et DFS sont nécessaires, Active Directory est requis, il est requis pour DFS, qui synchronisera le contenu du site entre les serveurs. RSAT est nécessaire pour gérer les composants et Windows Admin Center est nécessaire pour modifier le registre. Cela peut également être fait via Powershell, dont je discuterai également.

Le domaine de l'auteur s'appelle ***. ***. Wtf (veuillez ne pas avoir peur), et les serveurs sont nommés d'après les centres de données et ont les noms de la forme cache-zur1, cahe-ru et ainsi de suite. AD est déployé et les serveurs y sont connectés. Maintenant en ordre.

Sélection de points

RUVDS possède 8 centres de données - 3 en Europe et 5 en Russie. Mon choix s'est porté sur Rucloud à Moscou et LD8 (celui de Londres). Rucloud parce qu'il n'est presque pas différent du M9, et à travers Londres il y a un câble transcontinental vers les USA, donc en Europe c'est un must have. Pour une distribution plus étroite en Europe, vous pouvez choisir la Suisse ou l'Allemagne - cela, en général, vous pouvez vous arrêter.

Choisir un DNS GeoIP

Si le client frappe sur le site, alors comment comprendre quel serveur doit lui transmettre les données? Utiliser le DNS bien sûr. Autrement dit, en fonction de l'adresse IP de celui qui a adressé le DNS, une réponse pertinente sera donnée.

Nous pouvons utiliser notre propre DNS (BIND avec un plugin pour Maxmind) ou une solution clé en main (Route53). Un abonnement aux bases de données Maxmind GeoIP coûte 25 $ par mois et Route53 coûte 0,50 $ par zone de domaine, plus un sou si vous optez pour un million de demandes. De plus, créer un autre point de renforcement des attaques DDoS est la dernière chose, donc mon choix s'est porté sur Route53.

Cet article concerne le CDN pour l'Europe; si vous avez besoin d'un CDN pour la Russie, le choix vers votre propre DNS est évident, car Route53 fournit un routage par pays, pas par ville.
Microsoft propose des services similaires (Azure Traffic Manager).

1. Installez IIS

1.1. Installation d'IIS

Nous installons les composants de base d'IIS, le composant de prise en charge des certificats centralisés, et sur le serveur principal une prise en charge supplémentaire pour la gestion à distance. Ce composant n'est nécessaire que pour un serveur - vous ne pourrez pas gérer d'autres serveurs lors de l'activation des configurations partagées, même si la gestion à distance a été configurée.



Via Powershell:

Install-WindowsFeature Web-Server, Web-CertProvider 

Sur le serveur principal, vous devez en outre installer:

 Install-WindowsFeature Web-Mgmt-Service 

1.1.1 Allumer la télécommande

Pour pouvoir gérer à distance le serveur IIS, nous devons augmenter le service de gestion à distance IIS. Sur le serveur principal, démarrez le service:

 start-service WMSVC set-service -Name WMSVC -StartupType Automatic 

Et maintenant, nous incluons la possibilité de gérer en tant que telle via le registre.

 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebManagement\Server 

La façon la plus simple de gérer le registre est bien sûr d'utiliser le Centre d'administration Windows.



Mais cela peut également être fait via Powershell:

 Set-Itemproperty -path "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebManagement\Server" -Name "EnableRemoteManagement" -value "1" 

Dans Windows Server 2012 et 2016, la règle de pare-feu ne se lève pas d'elle-même; vous devez modifier le pare-feu.

 Set-NetFirewallRule -Name IIS-WebServerRole-WMSVC-In-TCP -Enabled True 

Vérifiez s'il a augmenté:

 Test-NetConnection 8.8.8.8 -port 8172 

Trois modifications à trois endroits différents et maintenant nous pouvons nous connecter via le gestionnaire IIS à notre serveur en utilisant un autre serveur avec un bureau. C'était uniquement pour la commodité de la gestion ultérieure.

1.2 Nous avons réduit la centralisation des configurations

Il n'y a pas de boutons pour installer des configurations et des certificats centralisés dans IIS Manager, ils ne se trouvent que dans le gestionnaire de serveur local, donc pour Server Core, vous devrez tout faire via Powershell.

La centralisation des configurations et des certificats s'effectue via SMB. Par conséquent, j'ai créé deux utilisateurs privés de droits (séparément pour les configurations et séparément pour les certificats) qui n'ont accès en lecture qu'à leur dossier et les ai nommés certadmin et configadmin.

Il est conseillé aux utilisateurs d'être locaux sur le serveur principal - si votre contrôleur de domaine meurt, les applications qui s'accrochent à la configuration et aux certificats via SMB au nom de l'utilisateur du domaine mourront. L'utilisation d'utilisateurs locaux élimine cette situation.

1.2.1 Créer un dossier partagé

Deux dossiers publics doivent être stockés sur l'un des serveurs, d'où nous obtenons la configuration et les certificats. Comme chemin d'accès au dossier partagé, nous prenons le chemin par défaut pour les configurations IIS:

 New-SmbShare -ReadAccess configadmin@**.**wtf -Path C:\windows\System32\Inetsrv\Config -Name sharedconfigs 

Et pour les certificats, nous pouvons en choisir. Je les mets dans un dossier avec IIS.

 New-SmbShare -Path C:\inetpub\centralizedcerts -Name sharedconfigs -ReadAccess configadmin 

1.2.2 Nous connectons les nœuds aux configurations

Les paramètres doivent être définis uniquement pour les serveurs qui liront cette configuration. Mon serveur principal sous le nom cache-ru sera la tête, j'ai donc configuré les deux autres.
Entrez le mot de passe de l'utilisateur qui a accès au dossier:

 $pass = Read-Host -AsSecureString Enable-IISSharedConfig -PhysicalPath \\cache-ru.**.**wtf\SharedConfig -UserName configadmin@**.**wtf -Password $pass -DontCopyRemoteKeys 

Immédiatement après l'ouverture d'une nouvelle session devrait s'ouvrir. Pour vérifier que tout a fonctionné, vous pouvez ouvrir RSAT → Gestion de l'ordinateur → Dossiers partagés → Sessions. Nous verrons les sessions utilisateur et l'adresse IP du serveur, qui sous cet utilisateur lit le dossier partagé. Côté client, il est vérifié par l'applet de commande:

 Get-IISSharedConfig 

Voici à quoi cela ressemblait pour moi:



1.2.2 Connecter les nœuds aux certificats

La ligne suivante ne peut être saisie que directement, ayant une connexion directe au bureau exécutant le serveur avec une interface graphique, elle ne fonctionne pas sur Server Core.

 $pass = Read-Host -AsSecureString Enable-IISCentralCertProvider -CertStoreLocation \\cache-ru.**.**wtf\centralizedcerts -UserName certadmin@**.**wtf -Password $pass 

Si vous essayez de le saisir via Winrm, vous verrez la sortie suivante:



Pour ce faire à distance, vous devez modifier le registre. Comme c'est pratique! Nous volons dans:

 HKLM:\SOFTWARE\Microsoft\IIS\CentralCertProvider\ 

Créez un DWORD 32 bits «activé» avec le paramètre «1»:

 Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\IIS\CentralCertProvider\ -Name Enabled -Value 1 

Ensuite, nous créons la valeur de chaîne CertStoreLocation avec le paramètre \\ cache-ru. **. ** wtf \ centralizedcerts:

 Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\IIS\CentralCertProvider\ -Name CertStoreLocation -Value <a href="about:blank">\\cache-ru.**.**wtf\centralizedcerts</a> 

Pour vérifier si tout est en ordre, nous utilisons:

 Get-IISCentralCertProvider 

La sortie devrait être comme ceci:



Et seulement après cela, nous entrons:

 $pass = Read-Host -AsSecureString Set-IISCentralCertProvider -UserName certadmin@**.**wtf -Password $pass 

Vérifiez à nouveau:

 Get-IISCentralCertProvider 

Tout ce qui est sorti de la boîte est appelé. Contrairement aux configurations courantes, les certificats centralisés ne créent pas de session SMB active.

1.2.3 Brotli

Sur chaque serveur, téléchargez et exécutez le fichier de compression IIS

 Start-Process .\iiscompression_amd64.msi -ArgumentList /quiet 

Nous avons déjà partagé les configurations, vous devez donc configurer quelque chose en un seul endroit. En utilisant IIS Manager, nous allons dans l'éditeur de configuration sur le serveur principal.

 system.webServer/httpCompression 

Et définissez StaticCompressionLevel sur 11 pour Brotli et 9 pour Gzip, c'est le maximum qu'ils peuvent faire.

1.2.4 MIME et en-têtes

Hors de la boîte, IIS ne transmet pas l'en-tête de codage, c'est pourquoi l'alphabet cyrillique se transforme en runes. De plus, dans MIME, aucune entrée au format Webp ne doit être ajoutée.

1. Accédez au répartiteur → MIME. Recherchez .HTML et modifiez son type en: text / html; charset = utf-8



2. N'oubliez pas Webp - vous devez ajouter ce MIME manuellement.

2. Nous délivrons un certificat

Utilisation de Winacme . Tout d'abord, vous devez lier les domaines au site - cela peut être fait via le gestionnaire IIS. Lors de la création d'un CDN, ne sélectionnez pas la vérification de l'hôte, car les problèmes commencent immédiatement avec la confirmation de la propriété du domaine, notre choix est la vérification par enregistrement TXT. Vous devrez conduire manuellement le chemin d'accès au dossier contenant les certificats, ainsi que copier manuellement l'enregistrement du défi. Maintenant, mettez de l'air dans votre poitrine.

Afin de ne pas tout imprimer manuellement, activez RDP sur Server Core avec la commande suivante:

 cscript C:\Windows\System32\Scregedit.wsf /ar 0 

Voici à quoi ressemble RDP sur Server Core:



Après le défi, les certificats tombent dans le dossier spécifié dans Winacme. Winacme place la tâche dans le planificateur pour renouveler le certificat. Installé et oublié.



Eh bien, comme nous avons terminé, nous pouvons désactiver RDP - nous avons installé Server Core pour une bonne raison, nous avons découvert tant de nuances.

 cscript C:\Windows\System32\Scregedit.wsf /ar 1 

3. Certificat Bindim aux nœuds

Vous devez maintenant configurer deux autres nœuds pour que HTTPS fonctionne enfin. À l'heure actuelle, sur le serveur sur lequel les certificats sont stockés, HTTPS est déjà en cours d'exécution. Pour que les autres commencent à travailler sur HTTPS, eh bien, en général, cela se fait via netsh.

Comme d'habitude, nous nous connectons à Windows Server Core via RDP pour exécuter ce composant logiciel enfichable. Ne regardez pas le site de Microsoft, en particulier dans ce guide. Les étapes qu'il contient ne sont pas décrites correctement.

En utilisant netsh http show sslcert, sur le nœud maître, vous devez obtenir l'appid, que nous entrons comme décrit ci-dessous:

 netsh http add sslcert ccs=443 appid= '{4dc3e181-e14b-4a21-b022-59fc669b0914}' 

La valeur appid doit être entre guillemets, sinon cela ne fonctionnera pas.

4. Installez DFS

Ne synchronisez pas les certificats et les configurations via DFS, des outils spécialisés ont été inventés pour une raison. J'ai essayé et cela s'est avéré mal, pour une raison peu claire, les configurations sur les serveurs qui ont pris la config ont juste arrêté de lire les modifications, bien que pour la première fois tout ait fonctionné. Je n'ai pas trouvé la cause de l'échec et j'ai décidé de le faire différemment.

La configuration supplémentaire se fait exclusivement via RSAT, les applets de commande spécifiées dans la documentation ne fonctionnent que sous Windows Server avec une interface graphique. Le déploiement de la réplication DFS à l'aide de Server Core exclusivement n'est pas possible. Vous avez besoin d'un autre serveur avec une interface graphique ou d'un ordinateur exécutant Windows 10 Pro avec RSAT installé, joint au domaine.

2.1. Installer

Sur chaque serveur, vous devez installer la réplication DFS:

 Install-WindowsFeature FS-DFS-Replication, FS-DFS-Namespace 

2.2. Création d'un nouveau groupe de réplication



Vous devez d'abord appeler notre groupe de réplication.



Choisissez la topologie à votre goût. Personnellement, il sera plus pratique pour moi d'ajouter du contenu à un seul endroit, alors je choisis une étoile.





L'un des serveurs doit être le principal, c'est à partir de là que la réplication commence. Si vous téléchargez des fichiers vers des écouteurs, le fichier téléchargé n'est pas répliqué.



En tant que dossier de réplication, j'ai choisi le dossier par défaut avec les sites:

 C:\inetpub\wwwroot 

Ce dossier est le chemin d'accès au répertoire de ce premier serveur particulier. Vous pouvez répliquer le contenu de ce dossier n'importe où, quel que soit le chemin d'accès.



Au sein d'un même groupe, nous pouvons répliquer plusieurs dossiers, et à l'avenir, nous pouvons étendre leur liste si nécessaire.



Terminé.

5. Tester les performances

Pour comprendre combien de visiteurs sur le site ont réellement gagné, vous devez prendre des mesures. Ils seront menés à partir de deux points. PC d'auteur à Moscou et serveur virtuel à Francfort. Les trois points seront testés séparément. Voici un résumé.



Nous allons dans Devtools et regardons la cascade. En moyenne, dans un hôpital, un CDN réduira d'environ 200 millisecondes avant qu'un site ne soit complètement chargé. L'image, le plus grand objet de la page, est chargée dès qu'elle entre dans la fenêtre, faites donc attention à la ligne verticale bleue. CDN a accéléré les styles et scripts HTML + purs de 10 à 15 millisecondes, et l'image chargée 220 millisecondes plus rapidement, c'est une différence très significative.




J'ai également mesuré la vitesse de Jekyll sur un hôte local:



Nous nous tournons vers le phare et voyons des résultats étranges:





Dans ce synthétiques, un serveur qui terres lointaines contourne l'hôte local. Mais pourquoi?
Pour le plaisir, débarrassons-nous des polices Google et transférons-les sur nos serveurs.





Les résultats entre les centres de données sont alignés. Mais cela n'explique toujours rien. J'ai refait les tests plusieurs fois, les résultats sont absolument irréprochables et reproductibles à tout moment.

Nous allons maintenant utiliser un VPS avec deux cœurs et 4 gigaoctets de RAM situé à Francfort et voir ce qu'il dit. Cascades:




Ici, avec le bon point, les gains de temps uniquement sur les styles et le HTML s'élevaient à 200 millisecondes. Autrement dit, dans le cas d'un client de Francfort, le site sera simplement plus rapide de 200 millisecondes. Cela se reflète également dans le phare. Dans de tels cas, CDN accélérera non seulement la boutique en ligne, mais aussi un blog simple.




Maintenant, activez Google Fonts et regardez à nouveau le phare.




Malheureusement, je n'ai plus de points sur lesquels effectuer des tests, donc je vais terminer.

Conclusions

• Un CDN pour la sortie de toutes les statistiques est nécessaire, surtout quand il s'agit d'images lourdes ou de longs scripts.
• L'utilisation de Google Fonts est possible et nécessaire, dans les scénarios lourds, cela accélère vraiment le site.
• Le serveur principal, si vous décidez de faire tout cela sous Windows, il est conseillé d'avoir une interface graphique.
• Les utilisateurs qui prendront les configurations depuis le serveur principal sont mieux rendus locaux - en cas de défaillance du contrôleur de domaine, les nœuds peuvent perdre la connexion avec les configurations et les certificats, et le pool d'applications sera arrêté, car ne pourra pas lire une config.