Hello!
Nikita sedang berhubung - seorang jurutera sistem daripada syarikat itu SEMrush. Hari ini saya akan memberitahu anda tentang cara kami menghadapi tugas memastikan kestabilan perkhidmatan semrush.com kami di China, dan masalah yang kami hadapi semasa pelaksanaannya (memandangkan lokasi pusat data kami di pantai timur Amerika Syarikat).
Ini akan menjadi cerita besar, dibahagikan kepada beberapa artikel. Saya akan memberitahu anda bagaimana semuanya berlaku untuk kami: daripada perkhidmatan yang tidak berfungsi sepenuhnya dari China, kepada penunjuk prestasi perkhidmatan pada tahap versi Amerika untuk orang Amerika. Saya berjanji ia akan menarik dan berguna. Jadi, mari pergi.
Masalah Internet Cina
Malah orang yang paling jauh dari butiran pentadbiran rangkaian pernah mendengarnya Tembok Api Besar China. Wow, bunyinya keren, kan? Tetapi apakah itu dan bagaimana ia sebenarnya berfungsi adalah soalan yang agak rumit. Anda boleh menemui banyak artikel di Internet yang dikhaskan untuk ini, tetapi dari sudut pandangan teknikal, struktur tembok api ini tidak diterangkan di mana-mana sahaja. Yang, bagaimanapun, tidak menghairankan. Saya akan mengakui dengan segera bahawa berdasarkan hasil kerja setahun, saya tidak akan dapat mengatakan dengan tepat cara ia berfungsi, tetapi saya boleh memberitahu anda tentang ulasan dan kesimpulan praktikal saya. Dan kita akan mulakan dengan khabar angin tentang tembok api ini.
Terdapat banyak khabar angin tentang tembok api ini. Mari kumpulkan yang utama dan paling menarik daripada mereka ke dalam satu senarai:
- Google, Facebook, Twitter dan perkhidmatan lain yang serupa disekat dan tidak berfungsi di China.
- Sebarang trafik ke LUAR China dan KE China dihuraikan dan dihadkan menggunakan pembelajaran mesin (dalam kes trafik yang mencurigakan), yang sangat memperlahankannya (lalu lintas) melalui sempadan.
- Agensi perisikan China akan menggodam sebarang trafik yang disulitkan yang melalui tembok api mereka.
- Terowong VPN, terowong IPSEC tidak stabil, ranap dan sentiasa disekat.
- Lebih mudah penyulitan, lebih mudah frasa laluan yang digunakan untuk mengesahkan/menyulitkan trafik, lebih pantas ia melalui tembok api Cina.
Inilah yang kami ketahui tentang khabar angin ini:
- Google, Facebook, Twitter dan perkhidmatan lain yang serupa memang disekat (KO anda), tetapi banyak domain Google teknikal, contohnya, tidak diharamkan dan berfungsi (gstatic.com yang sama). Kesimpulan berikut dari ini: anda tidak sepatutnya memotong semua Google dan sumber lain yang nampaknya disekat secara melulu.
- Sebarang trafik yang melepasi sempadan benar-benar menambah kelewatan yang serius pada masanya. Tengok dua hasil. Satu tapak, satu halaman, GET mudah curl'om. Ukuran pertama adalah dari China sendiri (bandar Shenzhen yang indah). Yang kedua diukur dari luar dari Hong Kong (ia mempunyai kedaulatan, dan tiada tembok api antaranya dan dunia). Jarak antara bandar dalam garis lurus adalah lebih kurang 30-40 km.
nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 381k 0 381k 0 0 71824 0 --:--:-- 0:00:05 --:--:-- 82832
time_namelookup: 0.004500
time_connect: 0.169342
time_appconnect: 0.723189
time_pretransfer: 0.723499
time_redirect: 0.000000
time_starttransfer: 1.532912
----------
time_total: 5.443407
----------
size_download: 390968 Bytes
speed_download: 71824.000B/s
nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 319k 0 319k 0 0 2555k 0 --:--:-- --:--:-- --:--:-- 2573k
time_namelookup: 0.029366
time_connect: 0.030742
time_appconnect: 0.047310
time_pretransfer: 0.047388
time_redirect: 0.000000
time_starttransfer: 0.120793
----------
time_total: 0.124871
----------
size_download: 326755 Bytes
speed_download: 2616740.000B/sBeri perhatian kepada sambung masa. Dan secara umum, anda melihat hasilnya: tembok api menambah 4 saat tambahan, yang sangat panjang.
- Terowong VPN dan IPSEC sering gagal. Saya akan bercakap tentang ini sedikit kemudian dan dengan lebih terperinci. Pelayan VPN yang digunakan oleh pengguna disekat dari semasa ke semasa (biasanya dalam masa sehari selepas permulaan penggunaan).
- Terdapat pendapat yang diterima daripada orang yang tinggal di China bahawa lebih mudah penyulitan lalu lintas, lebih cepat ia melalui sempadan, kerana mudah difahami bahawa tidak ada yang menyalahi undang-undang mengenainya. Dan dengan cara yang sama, trafik "bersih" menerima lebih lebar jalur dan kelajuan laluan, manakala trafik "kotor", di mana tiada apa yang dapat dihuraikan, menerima, sebaliknya, laluan yang lebih perlahan. Sebagai contoh saya akan menggunakan curl to ifconfig.co melalui protokol HTTPS dan HTTP.
curl -o /dev/null -w@curl_time "https://ifconfig.co/"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13 100 13 0 0 2 0 0:00:06 0:00:05 0:00:01 3
time_namelookup: 0.004305
time_connect: 0.397465
time_appconnect: 5.149305
time_pretransfer: 5.149393
time_redirect: 0.000000
time_starttransfer: 5.568847
----------
time_total: 5.568893
----------
size_download: 13 Bytes
speed_download: 2.000B/s
curl -o /dev/null -w@curl_time "http://ifconfig.co/"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13 100 13 0 0 28 0 --:--:-- --:--:-- --:--:-- 28
time_namelookup: 0.004282
time_connect: 0.212457
time_appconnect: 0.000000
time_pretransfer: 0.212484
time_redirect: 0.000000
time_starttransfer: 0.450565
----------
time_total: 0.450620
----------
size_download: 13 Bytes
speed_download: 28.000B/sPerbezaan 5 saat untuk jumlah masa muat turun sebanyak 13 bait. Lebih-lebih lagi, apabila melakukan ujian sedemikian beberapa kali, anda dapat melihat bahawa GET pada HTTP diselesaikan secara amnya pada masa yang sama setiap kali, manakala pada HTTPS tapak kadangkala bertindak balas dalam 3, 5, 10 dan juga 17 saat. Kadangkala ralat SSL berlaku:
Unknown SSL protocol error in connection to ifconfig.co:443.
Jadi apa yang kita ada:
- Masalah yang dicipta oleh tembok api Cina diterangkan di atas.
- Ping kepada sumber luar dan dalam terowong hilang secara berkala.
- Latensi antara dua titik sentiasa berubah, dan selalunya ia tidak dapat diramalkan. Apabila menyambungkan bandar/rantau yang berbeza, anda menjangkakan bahawa, berdasarkan lokasi geografi wilayah, kelewatan akan menjadi kurang, tetapi anda mendapat situasi yang bertentangan.
- Internet dan saluran komunikasi sama ada pantas atau lambat. Terdapat sedikit pergantungan pada masa hari dan hari dalam seminggu, tetapi tidak selalu.
- Permintaan DNS kepada dunia luar dari China kadangkala melebihi tamat masa yang dibenarkan.
Gambar yang muncul hanyalah "cemerlang."
Pusat data, seperti yang telah saya katakan, berada di timur Amerika Syarikat, dan keseluruhan SEMrush terdiri daripada berpuluh-puluh produk yang saling berkaitan, bahagian belakang, bahagian hadapan, pangkalan data, dan semua ini di DC dan awan. Kami, sebagai pasukan pentadbir sistem, diberi tugas untuk mula bekerja dengan cepat di China dengan sedikit usaha.
Kami terpaksa menjawab soalan penting: adakah mungkin untuk bertahan dengan sedikit perbelanjaan dan menyelesaikan semua masalah yang berkaitan dengan Internet Cina dan tembok api di peringkat rangkaian/awan/pelayan?
Kami mulakan dengan menerima .
lesen ICP
Untuk dapat mengehoskan perkhidmatan anda di China (Tanah Besar China) dan menjalankan ujian, anda mesti mendapatkan lesen ICP untuk domain tersebut terlebih dahulu.
Jika trafik pengguna tapak anda ditamatkan dalam Tanah Besar China dan jika domain anda tidak mempunyai lesen ICP, trafik anda akan disekat di bahagian ISP/penghosan. Menariknya, pembekal tertentu sesuai dengan lesen ICP, sama ada Cloudflare atau Alibaba Cloud. Oleh itu, jika anda menerima lesen ICP untuk Cloudflare dan mengehos tapak web anda dengan mereka, anda tidak akan dapat "dengan lancar" berpindah ke Alibaba Cloud. Anda perlu menambah pengehosan lain pada lesen ini.
Setelah menerima lesen ICP untuk domain, kami dapat menghasilkan dan melaksanakan idea dan penyelesaian teknikal tertentu.
Penyelesaian ujian
Tetapi sebelum anda terus membuat pilihan pementasan, putar tombol, optimumkan prestasi tapak dan kelajuannya, anda perlu memilih alat untuk mengujinya untuk melihat tindakan kami yang mana yang bertambah baik atau, sebaliknya, memburukkan prestasi tapak.
Alat ujian kami perlu memenuhi dua keperluan utama:
- ia sepatutnya dapat menjalankan ujian dari China,
- ia mesti mempunyai ujian pelayar.
Jadi kami jumpa ! Mereka mempunyai liputan yang sangat baik untuk lokasi ujian di seluruh dunia. Di China, ujian juga boleh dijalankan dari 100500 wilayah melalui alat ini. Setiap satu mempunyai beberapa pembekal berbeza + keupayaan untuk melakukannya Tulang Belakang-ujian (sesuatu seperti mesin maya dalam pusat data) dan Lastmile-ujian (sedekat mungkin dengan keadaan pengguna, aka stesen kerja). Jenis ujian yang terakhir lebih mahal.
Setelah membuat kontrak tahunan (tidak kurang mungkin), kami mula mengkaji instrumen itu. Terus terang, kami terkejut dengan fungsinya. Anda boleh menjalankan:
- ujian DNS,
- Ujian web (ujian penyemak imbas, GET/POST mudah, emulasi pelanggan mudah alih, dll.),
- Pemeriksaan transaksi (contohnya, log masuk),
- ujian API,
- Ping, traceroute, NTP, dll.
Anda tidak boleh menyenaraikan semuanya. Dan yang paling penting, setiap ujian boleh disesuaikan dengan agak baik dengan menambahkan sekumpulan pengepala dan parameter lain. Outputnya ialah sejumlah besar maklumat yang menerangkan sepenuhnya ujian anda. Jika kita bercakap tentang perkara yang paling menarik untuk kita (ujian penyemak imbas), hasilnya termasuk:
- Sambung, Tunggu, Muatkan, SSL, masa DNS,
- TTFB, TTLB, Dokumen selesai, Masa render, beban DOM,
- Respons (sesuatu yang hampir dengan Time To First Byte), Response Halaman Web (sesuatu yang hampir dengan Time To Last Byte),
- Sebarang persentil, Purata, Masa Median
- Dan lain-lain.
Sehubungan itu, semua metrik ini bagus untuk melihat perubahan dan memahami sama ada keadaan telah bertambah baik. Kami terutamanya melihat Respons, Respons Halaman Web, Median, 75 dan 95 Peratus.
Satu soalan penting yang didengari sejak awal lagi: Bolehkah anda mempercayai Catchpoint?? Adakah alat ini mencerminkan kelajuan pemuatan tapak sebenar di China dari bandar yang berbeza, atau adakah ia hanya sejenis ujian dalam vakum yang tiada kaitan dengan pengalaman pengguna sebenar?
Ini adalah masalah besar, kerana berada di Rusia hampir mustahil untuk mengetahui dengan pasti cara tapak dari China berfungsi. Dengan melakukan proksi stokin melalui mesin maya, hasil akhirnya ialah tapak dimuatkan dalam masa beberapa minit, yang sememangnya tidak boleh diterima untuk ujian, jadi satu-satunya pilihan untuk ujian manual ialah curl dan GET ringkas dari konsol dengan pemasa . Ini membantu kerana ujian ini mencerminkan kelajuan penyelesaian rangkaian, dan jika terdapat juga ujian penyemak imbas, maka ia adalah sangat baik.
Kemudian kami sendiri pergi ke China dan yakin itu Anda boleh mempercayai Catchpoint; ia menggambarkan penunjuk prestasi sebenar dengan tepat.
Rangkaian Cloudflare China
Memandangkan kami berjaya menggunakan Cloudflare untuk domain utama semrush.com, kami memutuskan untuk segera mencuba ciri mereka yang dipanggil . Pilihan ini hanya didayakan untuk tapak Perusahaan atas permintaan berasingan dan dengan bayaran tambahan. Ia juga hanya tersedia untuk tapak yang mempunyai lesen ICP yang sesuai yang menyenaraikan Cloudflare sebagai pembekal. Selepas mendayakannya, "CDN Cina" daripada Cloudflare menjadi tersedia untuk tapak - trafik dari wilayah China mendarat di CF PoP (Titik Kehadiran) terdekat, dan kemudian melalui rangkaiannya atau rangkaian pembekal/rakan kongsi ia dihantar ke asal .
Gambar rajah bangku ujian ini dibentangkan di bawah.
Ini adalah pilihan yang bagus untuk kami. Ternyata domain kedua juga untuk CF, yang tidak menambah bilangan penyelesaian yang digunakan dalam syarikat, dan juga secara praktikal tidak merumitkan infrastruktur.
Kami menjalankan ujian penyemak imbas dan inilah yang berlaku:
Berlian merah adalah kegagalan ujian. Fail di bawah ialah ralat DNS (selesaikan tamat masa). Kegagalan di bahagian atas adalah tamat masa.
Masa aktif: 86.6
Median: 18s
75 Peratusan: 29.3s
95 Peratusan: 60s
Median, selepas pemuatan dikeluarkan reCaptcha (Perkhidmatan Google disekat di China) menurun daripada 28 kepada 18 saat. Tetapi ini masih merupakan keputusan yang mengerikan, memandangkan ujian yang sama untuk semrush.com (dari AS) memberikan kurang daripada 10 saat untuk 95% pengguna (dari AS) pada halaman yang sama (statik + dinamik).
Anda boleh pergi ke setiap ujian dan lihat Air terjun dan parameter lain yang lebih terperinci. Kami mula menyiasat sebab-sebab kesilapan, dan jika untuk tamat masa semuanya lebih atau kurang jelas: Internet di China "bergerak masuk dan keluar", kerana ini kelajuan sambungan dan pemuatan sumber dari luar negara tidak stabil dan tidak sekata, maka ralat DNS amat mengejutkan kami . Kami mendapati itu Po Cloudflare sebenarnya terletak di China, alamat tapak diselesaikan kepada satu IP anycast, tetapi pelayan DNS adalah Amerika, itulah sebabnya permintaan DNS terpaksa merentasi sempadan, jadi kadangkala ia gagal.
Setelah menjelaskan soalan ini dengan CF, ternyata begitu Mereka tidak mempunyai pelayan DNS mereka sendiri di China, dan bila ia akan berlaku masih tidak diketahui.
Oleh itu, kami memutuskan untuk menguji hanya Cloudflare DNS dan menukar mekanisme pengendalian Cloudflare untuk tapak kami kepada "DNS sahaja" Ini ialah mod apabila Cloudflare tidak memproksi trafik melalui dirinya sendiri, yang bermaksud ia tidak menyediakan perlindungan DDoS, CDN dan ciri lain, dan beroperasi dalam mod pelayan DNS biasa.
Pendirian ini ditunjukkan secara skematik dalam rajah berikut. Angka itu mengambil kira pengetahuan yang baru muncul bahawa pelayan DNS Cloudflare berada di belakang tembok api.
Di Catchpoint kami menjalankan ujian GET yang mudah (bukan ujian penyemak imbas), yang menunjukkan banyak kegagalan. Ia disebabkan oleh ralat DNS yang sama.
Kami mula menyahpepijat ralat ini menggunakan menggali dan mendapati bahawa atas permintaan pertama alamat ditentukan dengan betul, dan atas permintaan berulang kami menerima setiap kali SERVFAIL и tidak ditemui. Mengapa ini berlaku secara tiba-tiba?
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)Apabila menanyakan pelayan Cloudflare NS secara langsung, tiada ralat sedemikian:
root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases:
semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases:
semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192Ini bermakna bahawa masalahnya terletak pada sisi pelayan DNS "tempatan" atau pelayan pembekal.
Siasatan lanjut mendedahkan itu SERVFAIL kita berazam aaaa-rekod.
Ternyata apabila meminta daripada Cloudflare AAAA-rekod yang tidak wujud dalam domain, Cloudflare menjawab А-entri yang ralat dan tidak mematuhi RFC. Mengapakah penyelesai tempatan (xxxx) Saya tidak menyukainya, dan dia menjawab SERVFAIL. Tingkah laku ini jelas kelihatan dalam log di bawah:
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;semrushchina.cn. IN AAAA
;; Query time: 334 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Aug 14 23:38:50 CST 2018
;; MSG SIZE rcvd: 44
root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;semrushchina.cn. IN AAAA
;; ANSWER SECTION:
semrushchina.cn. 300 IN A 220.170.186.192
;; Query time: 185 msec
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; WHEN: Tue Aug 14 23:43:03 CST 2018
;; MSG SIZE rcvd: 60
Kami menyerahkan laporan pepijat kepada Cloudflare, dan mereka membetulkannya selepas beberapa ketika. Ternyata menarik: buat masa ini masih tiada sokongan IPv6 di China, jadi Cloudflare tidak dapat mengeluarkan alamat IPv6nya di sana sebagai tindak balas kepada permintaan AAAA-rekod. Pada akhirnya, segala-galanya telah diselesaikan dengan cara yang Cloudflare mula menjawab untuk China TIADA DATA kepada permintaan sedemikian.
Oleh itu, ralat DNS dalam ujian Catchpoint menurun secara mendadak, tetapi tidak sepenuhnya. Tamat masa masih di sini:
Dan kami mula mencari penyelesaian lain.
Dalam bahagian seterusnya saya akan memberitahu anda bagaimana kami menguji awan Cina Alibaba Awan, bagaimana, dengan bantuan sedikit "ajaib" Nginx, kami dapat dengan cepat mencipta penyelesaian PoC (Proof of Concept), cara kami mencipta penyelesaian Multi-Cloud, salah satunya yang akhirnya sangat membantu mempercepatkan kerja perkhidmatan dari China.
Tinggal!
Bahagian seterusnya
Sumber: www.habr.com
