Hola habr En este artículo construiremos nuestro propio CDN. ¿Por qué no usar soluciones preparadas? Debido a que el sitio del autor es completamente estático, hecho en Jekyll, con imágenes grandes que deben ser entregadas lo más rápido posible. El servidor no debe estar en caché, debe almacenar todo el sitio, admitir HTTP / 2 y Brotli, y el mismo certificado debe estar instalado en todos los servidores.
También lo haremos todo en IIS que se ejecuta en Windows Server 2019 Core.
Brevemente sobre la implementación
En los nodos finales, administraremos los medios integrados en el sistema operativo, necesitaremos:
- Directorio Activo
- Dfs
- IIS
- Winacme
- RSAT
Opcional, pero recomendado:
- Centro de administración de Windows
En sitios con sitios, solo se necesitan IIS y DFS, se requiere Active Directory, se requiere para DFS, que sincronizará el contenido del sitio entre servidores. Se necesita RSAT para administrar los componentes y se necesita el Centro de administración de Windows para editar el registro. Esto también se puede hacer a través de Powershell, que también discutiré.
El dominio del autor se llama ***. ***. Wtf (no se alarme), y los servidores son nombrados por los centros de datos y tienen los nombres de la forma cache-zur1, cahe-ru, etc. AD se implementa y los servidores están conectados a él. Ahora en orden.
Selección de puntos
RUVDS tiene
8 centros de datos : 3 en Europa y 5 en Rusia. Mi elección recayó en Rucloud en Moscú y LD8 (el de Londres). Rucloud porque casi no es diferente del M9, y a través de Londres hay un cable transcontinental a los Estados Unidos, por lo que en Europa es imprescindible. Para una distribución más estricta en Europa, puede elegir Suiza o Alemania; esto, en general, puede detenerse.
Elegir un DNS GeoIP
Si el cliente llama al sitio, ¿cómo entender qué servidor debe transmitirle los datos? Usando DNS, por supuesto. Es decir, dependiendo de la dirección IP de la persona que se dirigió al DNS, se dará una respuesta relevante.
Podemos usar nuestro propio DNS (BIND con un complemento para Maxmind) o una solución llave en mano (Route53). Una suscripción a las bases de datos Maxmind GeoIP cuesta $ 25 por mes, y Route53 cuesta $ 0.50 por zona de dominio, más un centavo si va por un millón de solicitudes. Además, crear otro punto de fortalecimiento de los ataques DDoS es lo último, por lo que mi elección recayó en Route53.
Este artículo trata sobre CDN para Europa; si necesita un CDN para Rusia, entonces la elección hacia su propio DNS es obvia, porque Route53 proporciona enrutamiento por país, no por ciudad.
Microsoft tiene servicios similares (Azure Traffic Manager).
1. Instalar IIS
1.1. Instalación de IISInstalamos los componentes básicos de IIS, el componente de soporte para certificados centralizados y en el servidor principal soporte adicional para administración remota. Este componente es necesario solo para un servidor: no podrá administrar otros servidores cuando habilite configuraciones compartidas, incluso si se ha configurado la administración remota.
Vía Powershell:
Install-WindowsFeature Web-Server, Web-CertProvider
En el servidor principal, debe instalar adicionalmente:
Install-WindowsFeature Web-Mgmt-Service
1.1.1 Encienda el control remotoPara que podamos administrar de forma remota el servidor IIS, necesitamos elevar el Servicio de administración remota de IIS. En el servidor principal, inicie el servicio:
start-service WMSVC set-service -Name WMSVC -StartupType Automatic
Y ahora incluimos la capacidad de administrar como tal a través del registro.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebManagement\Server
La forma más fácil de administrar el registro, por supuesto, es a través del Centro de administración de Windows.
Pero esto también se puede hacer a través de Powershell:
Set-Itemproperty -path "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebManagement\Server" -Name "EnableRemoteManagement" -value "1"
En Windows Server 2012 y 2016, la regla del firewall no aumenta por sí sola; debe editar el firewall.
Set-NetFirewallRule -Name IIS-WebServerRole-WMSVC-In-TCP -Enabled True
Compruebe si ha aumentado:
Test-NetConnection 8.8.8.8 -port 8172
Tres ediciones en tres lugares diferentes y ahora podemos conectarnos a través del administrador de IIS a nuestro servidor utilizando otro servidor con un escritorio. Esto fue solo para la conveniencia de la gestión posterior.
1.2 Cortamos la centralización de configuracionesNo hay botones para instalar configuraciones centralizadas y certificados en el Administrador de IIS, solo están en el administrador del servidor local, por lo que para Server Core tendrá que hacer todo a través de Powershell.
La centralización de configuraciones y certificados se realiza a través de SMB. Por lo tanto, hice dos usuarios privados de sus derechos (por separado para configuraciones y por separado para certificados) que tienen acceso de lectura solo a su carpeta y los nombraron certadmin y configadmin.
Es aconsejable que los usuarios sean locales en el servidor principal: si su controlador de dominio muere, las aplicaciones que se aferran a la configuración y los certificados a través de SMB en nombre del usuario de dominio morirán. El uso de usuarios locales elimina esta situación.
1.2.1 Crear una carpeta compartidaDeben almacenarse dos carpetas públicas en uno de los servidores, de donde obtenemos la configuración y los certificados. Como la ruta a la carpeta compartida, tomamos la ruta predeterminada a las configuraciones de IIS:
New-SmbShare -ReadAccess configadmin@**.**wtf -Path C:\windows\System32\Inetsrv\Config -Name sharedconfigs
Y para los certificados podemos elegir cualquiera. Los puse en una carpeta con IIS.
New-SmbShare -Path C:\inetpub\centralizedcerts -Name sharedconfigs -ReadAccess configadmin
1.2.2 Conectamos nodos a configuracionesLa configuración debe hacerse solo para aquellos servidores que leerán esta configuración. Mi servidor principal con el nombre cache-ru será el jefe, así que configuré los otros dos.
Ingrese la contraseña del usuario que tiene acceso a la carpeta:
$pass = Read-Host -AsSecureString Enable-IISSharedConfig -PhysicalPath \\cache-ru.**.**wtf\SharedConfig -UserName configadmin@**.**wtf -Password $pass -DontCopyRemoteKeys
Inmediatamente después de ingresar una nueva sesión debe abrirse. Para verificar que todo funcionó, puede abrir RSAT → Administración de equipos → Carpetas compartidas → Sesiones. Veremos las sesiones de usuario y la dirección IP del servidor, que bajo este usuario lee la carpeta compartida. En el lado del cliente, el cmdlet lo verifica:
Get-IISSharedConfig
Así me pareció a mí:
1.2.2 Conectar nodos a certificadosLa siguiente línea solo se puede ingresar directamente, ya que tiene una conexión directa al escritorio que ejecuta el Servidor con una GUI, no funciona en Server Core.
$pass = Read-Host -AsSecureString Enable-IISCentralCertProvider -CertStoreLocation \\cache-ru.**.**wtf\centralizedcerts -UserName certadmin@**.**wtf -Password $pass
Si intenta ingresarlo a través de Winrm, verá el siguiente resultado:
Para hacer esto de forma remota, debe editar el registro. ¡Qué conveniente! Volamos en:
HKLM:\SOFTWARE\Microsoft\IIS\CentralCertProvider\
Cree un DWORD de 32 bits "Habilitado" con el parámetro "1":
Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\IIS\CentralCertProvider\ -Name Enabled -Value 1
Luego creamos el valor de cadena CertStoreLocation con el parámetro \\ cache-ru. **. ** wtf \ centralizedcerts:
Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\IIS\CentralCertProvider\ -Name CertStoreLocation -Value <a href="about:blank">\\cache-ru.**.**wtf\centralizedcerts</a>
Para verificar si todo está en orden, utilizamos:
Get-IISCentralCertProvider
La salida debería ser así:
Y solo después de eso entramos:
$pass = Read-Host -AsSecureString Set-IISCentralCertProvider -UserName certadmin@**.**wtf -Password $pass
Verifique nuevamente:
Get-IISCentralCertProvider
Todo fuera de la caja se llama. A diferencia de las configuraciones comunes, los certificados centralizados no crean una sesión SMB activa.
1.2.3 BrotliEn cada servidor, descargue y ejecute el archivo de
compresión IIS Start-Process .\iiscompression_amd64.msi -ArgumentList /quiet
Ya hemos compartido las configuraciones, por lo que debe configurar algo en un solo lugar. Usando el Administrador de IIS, vamos al editor de configuración en el servidor principal.
system.webServer/httpCompression
Y establezca StaticCompressionLevel en 11 para Brotli y 9 para Gzip, esto es lo máximo que pueden hacer.
1.2.4 MIME y encabezadosFuera de la caja, IIS no transmite el encabezado de codificación, por lo que el alfabeto cirílico se convierte en runas. También en MIME no hay entrada de formato webp que deba agregarse.
1. Vaya al despachador → MIME. Busque .HTML y modifique su tipo a: text / html; charset = utf-8
2. No se olvide de Webp: debe agregar este MIME manualmente.
2. Emitimos un certificado
Usando
Winacme . Primero, debe vincular los dominios al sitio; esto se puede hacer a través del Administrador de IIS. Al crear una CDN, no seleccione la verificación de host, ya que Los problemas comienzan inmediatamente con la confirmación de la propiedad del dominio, nuestra elección es la verificación por registro TXT. Tendrá que conducir manualmente la ruta a la carpeta con los certificados, así como copiar manualmente el registro del desafío. Ahora, lleva aire a tu pecho.
Para no imprimir todo manualmente, habilite RDP en Server Core con el siguiente comando:
cscript C:\Windows\System32\Scregedit.wsf /ar 0
Así es como se ve RDP en Server Core:
Después del desafío, los certificados caen en la carpeta que se especificó en Winacme. Winacme coloca la tarea en el planificador para renovar el certificado. Instalado y olvidado.
Bueno, cuando terminamos, podemos desactivar RDP: instalamos Server Core por una buena razón, descubrimos muchos matices.
cscript C:\Windows\System32\Scregedit.wsf /ar 1
3. Certificado de Bindim a los nodos
Ahora necesita configurar otros dos nodos para que HTTPS finalmente funcione. En este momento, en el servidor donde se almacenan los certificados, HTTPS ya se está ejecutando. Para que el resto comience a trabajar en HTTPS, bueno, en general, esto se hace a través de netsh.
Como estamos acostumbrados, nos conectamos a Windows Server Core a través de RDP para ejecutar este complemento. No mire el sitio en Microsoft, especialmente en
esta guía. Los pasos en él se describen incorrectamente.
Usando netsh http show sslcert, en el nodo maestro necesita obtener el appid, que ingresamos como se describe a continuación:
netsh http add sslcert ccs=443 appid= '{4dc3e181-e14b-4a21-b022-59fc669b0914}'
El valor de appid debe estar entre comillas, de lo contrario no funcionará.
4. Instalar DFS
No sincronice certificados y configuraciones a través de DFS, se inventaron herramientas especializadas por una razón. Lo intenté y resultó mal, por alguna razón poco clara, las configuraciones en los servidores que tomaron la configuración simplemente dejaron de leer los cambios, aunque por primera vez todo funcionó. No descubrí la causa del fallo y decidí hacerlo de manera diferente.
La configuración adicional se realiza exclusivamente a través de RSAT, los cmdlets que se especifican en la documentación solo funcionan en Windows Server con una GUI. No es posible implementar la replicación DFS utilizando Server Core exclusivamente. Necesita otro servidor con una GUI o una computadora con Windows 10 Pro con RSAT instalado, unido al dominio.
2.1. InstalarEn cada servidor necesita instalar la replicación DFS:
Install-WindowsFeature FS-DFS-Replication, FS-DFS-Namespace
2.2. Hacer un nuevo grupo de replicación
Primero debe llamar a nuestro grupo de replicación.
Elija la topología a su gusto. Personalmente, será más conveniente para mí agregar contenido a un lugar, así que elijo una estrella.
Uno de los servidores debe ser el principal, es a partir de él que comienza la replicación. Si carga archivos a los oyentes, el archivo cargado no se replica.
Como carpeta para la replicación, elegí la carpeta predeterminada con sitios:
C:\inetpub\wwwroot
Esta carpeta es la ruta al directorio de este primer servidor en particular. Puede replicar el contenido de esta carpeta en cualquier lugar, independientemente de la ruta.
Dentro de un grupo, podemos replicar varias carpetas, y en el futuro podemos expandir su lista si es necesario.
Terminado
5. Prueba de rendimiento
Para comprender cuánto ganaron realmente los visitantes del sitio, debe tomar medidas. Se realizarán desde dos puntos. PC del autor en Moscú y servidor virtual en Frankfurt. Los tres puntos se probarán por separado. Aquí hay un resumen.
Entramos en Devtools y observamos la cascada. En promedio en un hospital, un CDN reducirá aproximadamente 200 milisegundos antes de que un sitio esté completamente cargado. La imagen, el objeto más grande de la página, se carga tan pronto como ingresa a la ventana gráfica, así que preste atención a la línea vertical azul. CDN aceleró los estilos y scripts HTML + puros en 10-15 milisegundos, y la imagen se cargó 220 milisegundos más rápido, esta es una diferencia muy significativa.
También medí la velocidad de Jekyll en un host local:
Nos dirigimos a la casa de la luz y vemos resultados extraños:
En este sintético, un servidor que aterriza en lugares distantes evita al host local. Pero por que?
Por diversión, eliminemos Google Fonts y transfiéralos a nuestros servidores.
Resultados entre centros de datos alineados. Pero todavía no explica nada. Rehice las pruebas varias veces, los resultados son absolutamente férreos y reproducibles en cualquier momento.
Ahora usaremos un VPS con dos núcleos y 4 gigabytes de RAM ubicados en Frankfurt y veremos qué dice. Cascadas
Aquí, con el punto correcto, el ahorro de tiempo solo en estilos y HTML ascendió a 200 milisegundos. Es decir, en el caso de un cliente de Frankfurt, el sitio simplemente será más rápido en 200 milisegundos. Esto también se refleja en la casa de la luz. En tales casos, CDN acelerará no solo la tienda en línea, sino también un blog fácil.
Ahora encienda Google Fonts y mire la casa de la luz nuevamente.
Desafortunadamente, ya no tengo puntos para realizar pruebas, así que terminaré.
Conclusiones
- CDN para generar todas las estadísticas es necesario, especialmente cuando se trata de imágenes pesadas o secuencias de comandos largas.
- Usar fuentes de Google es posible y necesario, en escenarios pesados realmente acelera el sitio.
- El servidor principal, si decide hacer todo esto en Windows, es recomendable tener una GUI.
- Los usuarios que tomarán las configuraciones del servidor principal son mejor locales: en caso de una falla del controlador de dominio, los nodos pueden perder la conexión con las configuraciones y los certificados, y el grupo de aplicaciones se detendrá, porque no podrá leer una configuración.
