Untuk apa kita membangun CDN?

Hai Habr! Pada artikel ini kita akan membangun CDN kita sendiri. Mengapa tidak menggunakan solusi yang sudah jadi? Karena situs penulis sepenuhnya statis, dibuat di Jekyll, dengan gambar besar yang perlu diberikan secepat mungkin. Server tidak boleh caching, harus menyimpan seluruh situs, mendukung HTTP / 2 dan Brotli, dan sertifikat yang sama harus diinstal pada semua server.

Kami juga akan melakukan semuanya pada IIS yang berjalan pada Windows Server 2019 Core.

Secara singkat tentang implementasinya

Pada titik akhir, kita akan mengelola cara yang dibangun ke dalam sistem operasi, kita akan membutuhkan:

1. Direktori Aktif
2. Dfs
3. IIS
4. Winacme
5. RSAT

Opsional, tetapi disarankan:

1. Pusat Admin Windows

Di situs dengan situs, hanya IIS dan DFS yang diperlukan, Active Directory diperlukan, diperlukan untuk DFS, yang akan menyinkronkan konten situs antara server. RSAT diperlukan untuk mengelola komponen, dan Windows Admin Center diperlukan untuk mengedit registri. Ini juga bisa dilakukan melalui Powershell, yang juga akan saya bahas.

Domain penulis disebut ***. ***. Wtf (jangan takut), dan server diberi nama setelah pusat data dan memiliki nama formulir cache-zur1, cahe-ru, dan sebagainya. AD dikerahkan, dan server terhubung dengannya. Sekarang sudah beres.

Temukan titik

RUVDS memiliki 8 pusat data - 3 di Eropa dan 5 di Rusia. Pilihan saya jatuh pada Rucloud di Moskow dan LD8 (yang ada di London). Rucloud karena hampir tidak berbeda dari M9, dan melalui London ada kabel lintas benua ke Amerika Serikat, jadi di Eropa itu harus dimiliki. Untuk distribusi yang lebih ketat di Eropa, Anda dapat memilih Swiss atau Jerman - ini, secara umum, Anda dapat berhenti.

Memilih GeoIP DNS

Jika klien mengetuk situs, lalu bagaimana memahami server mana yang harus mengirimkan data kepadanya? Tentu saja menggunakan DNS. Yaitu, tergantung pada alamat ip orang yang menangani DNS, jawaban yang relevan akan diberikan.

Kita dapat menggunakan DNS kita sendiri (BIND dengan plugin untuk Maxmind) atau solusi turnkey (Route53). Berlangganan ke Maxmind GeoIP-database biayanya $ 25 per bulan, dan Route53 biaya $ 0,50 per zona domain, ditambah satu sen jika Anda pergi untuk satu juta permintaan. Selain itu, untuk membuat titik lain untuk memperkuat serangan DDoS adalah hal terakhir, jadi pilihan saya jatuh pada Route53.

Artikel ini tentang CDN untuk Eropa; jika Anda memerlukan CDN untuk Rusia, maka pilihan menuju DNS Anda sendiri sudah jelas, karena Route53 menyediakan perutean berdasarkan negara, bukan oleh kota.
Microsoft memiliki layanan serupa (Azure Traffic Manager).

1. Instal IIS

1.1. Instalasi IIS

Kami memasang komponen dasar IIS, komponen dukungan untuk sertifikat terpusat, dan pada server utama dukungan tambahan untuk manajemen jarak jauh. Komponen ini diperlukan hanya untuk satu server - Anda tidak akan dapat mengelola server lain ketika mengaktifkan konfigurasi bersama, bahkan jika manajemen jarak jauh telah dikonfigurasi.



Via Powershell:

Install-WindowsFeature Web-Server, Web-CertProvider 

Di server utama, Anda harus menginstal:

 Install-WindowsFeature Web-Mgmt-Service 

1.1.1 Nyalakan remote control

Agar kita dapat mengelola server IIS dari jarak jauh, kita perlu meningkatkan Layanan Manajemen Jarak Jauh IIS. Di server utama, mulai layanan:

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

Dan sekarang kami menyertakan kemampuan untuk mengelola melalui registri.

 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebManagement\Server 

Cara termudah untuk mengelola registri, tentu saja, adalah melalui Windows Admin Center.



Tetapi ini juga bisa dilakukan melalui Powershell:

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

Di Windows Server 2012 dan 2016, aturan firewall tidak naik dengan sendirinya, Anda perlu mengedit firewall.

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

Periksa apakah sudah naik:

 Test-NetConnection 8.8.8.8 -port 8172 

Tiga suntingan di tiga tempat berbeda dan sekarang kita dapat terhubung melalui manajer IIS ke server kami menggunakan server lain dengan desktop. Ini hanya untuk kenyamanan manajemen selanjutnya.

1.2 Kami memotong sentralisasi konfigurasi

Tidak ada tombol untuk menginstal konfigurasi dan sertifikat terpusat di IIS Manager, mereka hanya di manajer server lokal, jadi untuk Server Core Anda harus melakukan semuanya melalui Powershell.

Sentralisasi konfigurasi dan sertifikat dilakukan melalui SMB. Oleh karena itu, saya membuat dua pengguna yang kehilangan haknya (secara terpisah untuk konfigurasi dan secara terpisah untuk sertifikat) yang hanya membaca akses ke folder mereka dan menamakan mereka certadmin dan configadmin.

Dianjurkan bagi pengguna untuk menjadi lokal di server utama - jika pengontrol domain Anda mati, maka aplikasi yang melekat pada konfigurasi dan sertifikat melalui SMB atas nama pengguna domain akan mati. Penggunaan pengguna lokal menghilangkan situasi ini.

1.2.1 Membuat folder bersama

Dua folder publik harus disimpan di salah satu server, dari mana kita mendapatkan konfigurasi dan sertifikat. Sebagai jalur ke folder bersama, kami mengambil jalur default ke konfigurasi IIS:

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

Dan untuk sertifikat kita dapat memilih. Saya meletakkannya di folder dengan IIS.

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

1.2.2 Kami menghubungkan node ke konfigurasi

Pengaturan hanya perlu dilakukan untuk server yang akan membaca konfigurasi ini. Server utama saya di bawah nama cache-ru akan menjadi kepala, jadi saya mengkonfigurasi pada dua lainnya.
Masukkan kata sandi pengguna yang memiliki akses ke folder:

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

Segera setelah memasuki sesi baru harus terbuka. Untuk memverifikasi bahwa semuanya berfungsi, Anda dapat membuka RSAT → Manajemen Komputer → Folder Bersama → Sesi. Kami akan melihat sesi pengguna dan alamat ip server, yang di bawah pengguna ini membaca folder bersama. Di sisi klien, ia diperiksa oleh cmdlet:

 Get-IISSharedConfig 

Begini tampilannya bagiku:



1.2.2 Hubungkan node ke sertifikat

Baris berikutnya hanya dapat dimasukkan secara langsung, memiliki koneksi langsung ke desktop yang menjalankan Server dengan GUI, itu tidak berfungsi pada Server Core.

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

Jika Anda mencoba memasukkannya melalui Winrm, Anda akan melihat output berikut:



Untuk melakukan ini dari jarak jauh, Anda perlu mengedit registri. Betapa nyamannya! Kami terbang:

 HKLM:\SOFTWARE\Microsoft\IIS\CentralCertProvider\ 

Buat DWORD 32-bit "Diaktifkan" dengan parameter "1":

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

Kemudian kita membuat nilai string CertStoreLocation dengan parameter \\ cache-ru. **. ** wtf \ centralizedcerts:

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

Untuk memeriksa apakah semuanya beres, kami menggunakan:

 Get-IISCentralCertProvider 

Outputnya harus seperti ini:



Dan hanya setelah itu kita masuk:

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

Periksa lagi:

 Get-IISCentralCertProvider 

Semuanya di luar kotak disebut. Tidak seperti konfigurasi umum, sertifikat terpusat tidak membuat sesi SMB aktif.

1.2.3 Brotli

Di setiap server, unduh dan jalankan file Kompresi IIS

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

Kami telah membagikan konfigurasi, jadi Anda perlu mengonfigurasi sesuatu hanya di satu tempat. Menggunakan IIS Manager, kita pergi ke editor konfigurasi di server utama.

 system.webServer/httpCompression 

Dan atur StaticCompressionLevel ke 11 untuk Brotli dan 9 untuk Gzip, ini adalah maksimum yang dapat mereka lakukan.

1.2.4 MIME dan header

Di luar kotak, IIS tidak mengirimkan header pengodean, itulah sebabnya alfabet Cyrillic berubah menjadi rune. Juga di MIME tidak ada entri format webp yang perlu ditambahkan.

1. Pergi ke operator → MIME. Temukan .HTML dan modifikasi tipenya menjadi: teks / html; charset = utf-8



2. Jangan lupa tentang Webp - Anda perlu menambahkan MIME ini secara manual.

2. Kami mengeluarkan sertifikat

Menggunakan Winacme . Pertama, Anda harus mengikat domain ke situs - ini dapat dilakukan melalui Manajer IIS. Saat membuat CDN, jangan pilih verifikasi host, seperti masalah segera dimulai dengan konfirmasi kepemilikan domain, pilihan kami adalah verifikasi oleh data TXT. Anda harus mengarahkan jalur ke folder secara manual dengan sertifikat, serta menyalin catatan secara manual dari tantangan. Sekarang, bawa udara ke dada Anda.

Agar tidak mencetak semuanya secara manual, aktifkan RDP di Server Core dengan perintah berikut:

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

Seperti inilah tampilan RDP di Server Core:



Setelah tantangan, sertifikat jatuh ke folder yang ditentukan di Winacme. Winacme menempatkan tugas dalam penjadwal untuk memperbarui sertifikat. Dipasang dan lupa.



Nah, ketika kami selesai, kami dapat mematikan RDP - kami menginstal Server Core untuk alasan yang baik, kami menemukan begitu banyak nuansa.

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

3. Sertifikat Bindim ke node

Sekarang Anda perlu mengkonfigurasi dua node lain sehingga HTTPS akhirnya berfungsi. Saat ini, di server tempat sertifikat disimpan, HTTPS sudah berjalan. Sehingga sisanya mulai bekerja pada HTTPS, well, secara umum, ini dilakukan melalui netsh.

Seperti biasa, kita terhubung ke Windows Server Core melalui RDP untuk menjalankan snap-in ini. Jangan melihat situs di Microsoft, terutama dalam panduan ini . Langkah-langkah di dalamnya dijelaskan secara salah.

Menggunakan http netsh show sslcert, pada node master Anda perlu mendapatkan appid, yang kita masukkan seperti yang dijelaskan di bawah ini:

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

Nilai appid harus dalam tanda kutip, jika tidak maka tidak akan berfungsi.

4. Instal DFS

Jangan menyinkronkan sertifikat dan konfigurasi melalui DFS, alat khusus diciptakan karena suatu alasan. Saya mencoba dan ternyata buruk, untuk beberapa alasan yang tidak jelas, konfigurasi pada server yang mengambil konfigurasi baru saja berhenti membaca perubahan, meskipun untuk pertama kalinya semuanya bekerja. Saya tidak menemukan penyebab kegagalan dan memutuskan untuk melakukannya secara berbeda.

Konfigurasi lebih lanjut dilakukan secara eksklusif melalui RSAT, cmdlet yang ditentukan dalam dokumentasi hanya berfungsi di bawah Windows Server dengan GUI. Menyebarkan replikasi DFS menggunakan Server Core secara eksklusif tidak dimungkinkan. Anda memerlukan server lain dengan GUI, atau komputer yang menjalankan Windows 10 Pro dengan RSAT diinstal, bergabung ke domain.

2.1. Instal

Pada setiap server Anda perlu menginstal Replikasi DFS:

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

2.2. Membuat grup replikasi baru



Pertama, Anda perlu menghubungi grup replikasi kami.



Pilih topologi sesuai selera Anda. Secara pribadi, akan lebih mudah bagi saya untuk menambahkan konten ke satu tempat, jadi saya memilih bintang.





Salah satu server harus menjadi yang utama, dari situlah replikasi dimulai. Jika Anda mengunggah file ke pendengar, maka file yang diunggah tidak direplikasi.



Sebagai folder untuk replikasi, saya memilih folder default dengan situs:

 C:\inetpub\wwwroot 

Folder ini adalah jalur ke direktori server pertama khusus ini. Anda dapat mereplikasi konten folder ini di mana saja, apa pun lintasannya.



Dalam satu grup, kami dapat mereplikasi beberapa folder, dan di masa mendatang kami dapat memperluas daftar mereka jika perlu.



Selesai

5. Menguji kinerja

Untuk memahami jumlah pengunjung yang benar-benar menang, Anda perlu melakukan pengukuran. Mereka akan dilakukan dari dua poin. PC penulis di Moskow dan server virtual di Frankfurt. Ketiga poin akan diuji secara terpisah. Berikut ini ringkasannya.



Kami pergi ke Devtools dan menyaksikan air terjun. Rata-rata di rumah sakit, CDN akan mengurangi sekitar 200 milidetik sebelum situs terisi penuh. Gambar, objek terbesar pada halaman, dimuat segera setelah memasuki viewport, jadi perhatikan garis vertikal biru. CDN mempercepat gaya dan skrip HTML + murni hingga 10-15 milidetik, dan gambar memuat 220 milidetik lebih cepat, ini adalah perbedaan yang sangat signifikan.




Saya juga mengukur kecepatan Jekyll pada host lokal:



Kami beralih ke rumah cahaya dan melihat hasil aneh:





Dalam sintetik ini, server yang jauh mendarat memotong host lokal. Tapi mengapa?
Untuk bersenang-senang, mari singkirkan Google Font dan transfer ke server kami.





Hasil antara pusat data selaras. Tapi itu masih tidak menjelaskan apa pun. Saya mengulang tes beberapa kali, hasilnya benar-benar besi dan dapat diproduksi ulang setiap saat.

Sekarang kita akan menggunakan VPS dengan dua core dan 4 gigabytes RAM yang terletak di Frankfurt dan melihat apa yang dikatakannya. Air terjun:




Di sini, dengan poin yang tepat, penghematan waktu hanya pada gaya dan HTML berjumlah 200 milidetik. Artinya, dalam kasus klien dari Frankfurt, situs hanya akan lebih cepat dengan 200 milidetik. Ini juga tercermin dalam rumah lampu. Dalam kasus seperti itu, CDN akan mempercepat tidak hanya toko online, tetapi juga blog yang mudah.




Sekarang nyalakan Google Fonts dan lihat mercusuar lagi.




Sayangnya, saya tidak lagi memiliki poin untuk melakukan tes, jadi saya akan selesai.

Kesimpulan

• CDN untuk menghasilkan semua statika diperlukan, terutama ketika menyangkut gambar-gambar berat atau skrip panjang.
• Menggunakan Google Font adalah mungkin dan perlu, dalam skenario berat itu benar-benar mempercepat situs.
• Server utama, jika Anda memutuskan untuk melakukan semua ini pada Windows, disarankan untuk memiliki GUI.
• Pengguna yang akan mengambil konfigurasi dari server utama sebaiknya dibuat lokal - jika terjadi kegagalan kontroler domain, node mungkin kehilangan koneksi dengan konfigurasi dan sertifikat, dan Application Pool akan dihentikan, karena tidak akan dapat membaca konfigurasi.