Isi semula awan Amazon: pintu masuk fail AWS Storage Gateway menyegerakkan fail tempatan ke panduan penyelesaian kegagalan S3
Dalam seni bina awan hibrid, AWS S3 File Gateway adalah jambatan yang menghubungkan bilik komputer tempatan perusahaan dan penyimpanan awan AWS. Ini membolehkan aplikasi tempatan menulis fail ke gateway melalui protokol NFS atau SMB standard, dan gateway secara automatik menyegerakkan fail ini ke dalam baldi Amazon S3 secara tidak segerak.
Walau bagaimanapun, dalam operasi dan penyelenggaraan sebenar, banyak jurutera akan menghadapi"
Fail tempatan ditulis, tetapi tidak dapat dilihat di S3
"Atau"
Kesalahan permintaan pintu masuk, gangguan penyegerakan langsung
"Keadaan memalukan. Masalah seperti ini nampaknya mudah, tetapi mungkin melibatkan
Bil akaun, dasar kebenaran, masa rangkaian, cakera cache tempatan dan peraturan S3
Dan sebab-sebab lain.
Artikel ini menggabungkan pengalaman operasi dan penyelenggaraan lini pertama untuk menyusun satu set idea penyiasatan dari dangkal ke dalam untuk membantu anda mencari dan menyelesaikan masalah kegagalan penyegerakan Storage Gateway dengan cepat.
1. Langkah pertama: periksa perkhidmatan asas dan status akaun (premis yang tidak dapat diabaikan)
Sebelum menyelidiki pelbagai rangkaian dan konfigurasi kebenaran yang kompleks, kita mesti terlebih dahulu mengesahkan status kesihatan akaun AWS itu sendiri dan perkhidmatan asas.
1. Periksa status dan bil akaun AWS
Banyak pasukan cenderung mengabaikan yang paling asas ketika menyiasat perincian teknikal
Status akaun
。 Sekiranya akaun AWS ditangguhkan atau dibatasi kerana tunggakan sumber (seperti kebenaran panggilan API terhad), perkhidmatan latar belakang Storage Gateway tidak akan dapat menulis data ke S3.
Periksa item: Log masuk ke konsol AWS untuk memeriksa sama ada terdapat bil tunggakan atau permintaan pembekuan akaun di antara muka Billing.
Cadangan operasi dan penyelenggaraan: Apabila syarikat menggunakan persekitaran pengeluaran, mereka mesti memastikan saluran pengisian semula akaun AWS yang lancar dan mengkonfigurasi Billing Alert (Billing Alert). Pada masa yang sama, disarankan untuk mengikat kad kredit yang tersedia atau melengkapkan pengisian semula akaun AWS dan amaran kuota melalui ejen AWS yang patuh untuk mengelakkan gangguan saluran data tempatan ke awan kerana tunggakan secara tiba-tiba.
2. Periksa status operasi Gateway dan log kesihatan CloudWatch
Log masuk ke konsol AWS Storage Gateway untuk mengesahkan sama ada status Gateway adalah "Online" (dalam talian).
Sahkan sama ada Logs Kesihatan CloudWatch diaktifkan. Banyak pengecualian penyegerakan gerbang fail (seperti S3AccessDenied, GatewayClockOutOfSync, dll.) Akan dikeluarkan secara langsung dalam kumpulan log CloudWatch, yang merupakan asas paling langsung untuk mendiagnosis masalah tersebut.
2. Langkah 2: Pengesahan Identiti dan Penyiasatan Kebenaran IAM
Salah satu sebab yang paling biasa mengapa data tidak dapat ditulis ke S3 dari pintu masuk adalah
Kebenaran tidak mencukupi
。 Gerbang perlu melalui IAM Role (peranan) untuk S
3 tong untuk operasi membaca dan menulis.
[Pelanggan NFS/SMB Tempatan]
│ Tulis
▼
[AWS Storage Gateway mesin maya]
│Gunakan pengesahan dan tandatangan identiti IAM Role
▼
[Baldi Amazon S3]
1. Semak Dasar Kebenaran (Dasar) IAM Role
Periksa sama ada IAM Role yang terikat dengan pintu masuk mempunyai kebenaran asas berikut untuk baldi S3 sasaran:
S3: GetBucketLocation (Dapatkan kawasan baldi)
S3: ListBucket (Senarai kandungan baldi)
S3: GetObject (membaca objek)
S3: PutObject (Muat naik objek fail)
S3: PutObject Acl (jika tetapan berkaitan ACL dihidupkan)
2. Semak Strategi Bucket S3 (Bucket Policy)
Sahkan sama ada terdapat penolakan eksplisit dalam strategi tong (
Deny
) Penyataan. Contohnya:
Adakah ia menyekat akses hanya ke IP atau VPC tertentu, sambil menyekat IP keluar dari pintu masuk fail?
Adakah dasar untuk memaksa penghantaran HTTP diaktifkan, tetapi konfigurasi gerbang gagal dipadankan?
3. Kebenaran kunci penyulitan KMS (jika SSE-KMS dihidupkan)
Sekiranya baldi S3 sasaran membuka penyulitan kunci KMS (SSE-KMS) tersuai, IAM Role bukan sahaja mempunyai kebenaran S3, tetapi juga mesti
Dasar Kunci KMS
Kebenaran berikut diberikan dalam:
Kms: GenerateDataKey
Kms: Decrypt
Kekurangan kebenaran KMS akan menyebabkan pintu masuk memanggil
PutObject
Buang terus
Akses Denied
Kesilapan.
4. Sekatan Dasar Endpoint VPC
Sekiranya pintu masuk dan S3 berkomunikasi melalui VPC Endpoint (VPC Endpoint), anda perlu memeriksa sama ada Endpoint Policy membenarkan IAM Role mengakses tong S3 sasaran.
3. Langkah 3: Pemeriksaan penyegerakan masa rangkaian dan sistem
Storage Gateway mempunyai syarat yang sangat tinggi untuk sambungan rangkaian dan ketepatan masa sistem tempatan.
1. Sisihan masa sistem (GatewayClockOutOfSync)
AWS API bergantung pada mekanisme tandatangan permintaan, dan tandatangan sensitif terhadap masa. Sekiranya masa sistem mesin maya (VMware, Hyper-V, atau EC2) di mana Storage Gateway berada adalah sama dengan masa pelayan AWS
Penyimpangan melebihi
5 minit
, AWS akan menolak semua permintaan pintu masuk dan mengeluarkan dalam log
GatewayClockOutOfSync
Kesilapan.
Kaedah penyiasatan: Log masuk ke Konsol Tempatan (Local Console) dan periksa konfigurasi NTP.
Penyelesaian: Pastikan mesin maya gateway dapat menyambung ke pelayan NTP secara normal (seperti 0.amazon.pool.ntp.org atau perkhidmatan NTP dalaman perusahaan), atau menghidupkan fungsi penyegerakan waktu host.
2. Kelancaran port rangkaian keluar
Gerbang perlu membuat sambungan keluar ke pelayan AWS. Sahkan bahawa firewall atau kumpulan keselamatan tidak memintas port berikut:
443 (HTTPS): Port komunikasi teras antara pintu masuk dan AWS Storage Gateway dan titik akhir S3.
80 (HTTP): Diperlukan apabila pintu masuk diaktifkan (hanya fasa pengaktifan).
22 (SSH/Saluran Sokongan): Sekiranya anda perlu membuka saluran sokongan teknikal rasmi AWS.
4. Langkah 4: Kesulitan sumber cache dan perkakasan tempatan
Gerbang fail menggunakan seni bina "muat naik tak segerak latar belakang cache tempatan". Apabila jumlah penulisan tempatan sangat besar atau sumber perkakasan tidak mencukupi, fail akan tetap berada di cache tempatan dan tidak dapat diselaraskan ke awan dalam masa.
1. Data kotor cache terlalu tinggi (item pemantauan CachePercentDirty)
Buka CloudWatch Metrics dan cari pintu masuk
CachePercentDirty
(Peratusan data kotor) penunjuk.
Keadaan normal: naik setelah menulis data, dan turun kembali ke hampir 0% setelah muat naik selesai.
Keadaan tidak normal: Sekiranya CachePercentDirty lebih tinggi daripada 80% untuk jangka masa yang panjang, ini bermaksud bahawa kelajuan penulisan pelanggan tempatan jauh lebih besar daripada kelajuan muat naik pintu masuk ke S3.
Strategi mengatasi
:
Periksa sama ada jalur lebar keluar penuh, dan tingkatkan lebar jalur rangkaian jika perlu.
Tambah lebih banyak cakera Cache tempatan ke pintu masuk.
Kawal kadar penulisan pada pelanggan untuk mengelakkan fail besar secara tiba-tiba dan menekan cache.
2. Kesesakan cakera tempatan I/O (IoWaitPercent)
Perhatikan di CloudWatch
IoWaitPercent
Penunjuk. Sekiranya nilai terus melebihi
10%
, Yang menunjukkan bahawa terdapat hambatan dalam prestasi membaca dan menulis cakera cache tempatan (misalnya, menggunakan HDD berkelajuan rendah dan bukannya SSD/NVMe).
Penyelesaian: Disarankan untuk mengganti cakera cache dengan cakera keras keadaan pepejal NVMe atau SSD yang tinggi IOPS; atau bahagikan cakera cache besar tunggal ke dalam cakera fizikal yang berasingan dan dipasang ke mesin maya untuk menyebarkan tekanan I/O.
3. Entri kebenaran Windows (ACL) terlalu panjang (Error 1344)
Sekiranya anda berkongsi fail melalui protokol SMB, ketika cuba menyegerakkan terlalu rumit Win
Fail yang ditetapkan oleh izin turun mungkin dicetuskan
Ertor: 1344 (0x00000540)
。
Sebab: AWS S3 File Gateway hanya menyokong penyimpanan sehingga 10 entri kawalan akses (ACEs) untuk setiap fail atau direktori.
Penyelesaian: Bersihkan dan selaraskan senarai hak akses Windows untuk fail atau folder, gabungkan kumpulan pengguna, dan pastikan bilangan ACE kurang dari 10.
5. Langkah 5: Perubahan sisi S3 tidak ditunjukkan secara tempatan (salah faham mengenai kognisi penyegerakan terbalik)
Terdapat kes khas yang sering disalah anggap sebagai "kegagalan penyegerakan":
Pengguna memuat naik fail secara langsung di konsol S3, tetapi tidak dapat melihatnya di titik pemasangan NFS/SMB tempatan
。
Prinsip: Untuk mengekalkan prestasi tinggi, gerbang fail akan menyimpan metadata S3. Secara lalai, ia tidak akan mengundi perubahan dalam tong S3 dalam masa nyata.
Penyelesaian: Refresh manual: pilih perkongsian fail di konsol, klik "Refresh Cache" (Refresh Cache), atau laksanakan perintah berhenti-cache melalui AWCLS I. Refresh automatik: Konfigurasikan selang waktu strategi penyegaran cache automatik dalam tetapan perkongsian fail.
Enam, periksa ringkasan CheckList
Apabila penyegerakan fail AWS Storage Gateway gagal, anda boleh merujuk jadual berikut untuk memeriksa tempat duduk dengan cepat:
Tahap penyiasatan
Periksa item
Fenomena biasa/kod ralat
Penyelesaian yang disyorkan
Asas dan bil
Status akaun AWS
Panggilan API ditolak, pintu masuk di luar talian
Isi semula akaun AWS tepat pada masanya untuk memastikan bahawa tidak ada tunggakan dan konfigurasi penggera baki
Kawalan kebenaran
IAM Role / S3 Policy / KMS
S3AccessDenied
Lengkapkan kebenaran PutObject dan kebenaran penyahsulitan KMS
Masa sistem
Penyegerakan masa NTP
GatewayClockOutOfSync
Menentukur masa NTP mesin maya gateway untuk memastikan penyimpangan kurang dari 5 minit
Sambungan rangkaian
443 port dengan VPC Endpoint
Waktu tamat rangkaian, sambungan gagal
Periksa peraturan keluar kumpulan keselamatan dan firewall
Prestasi perkakasan
Cakera cache dan CPU/memori
CachePercentDirty > 80%
Tingkatkan cakera cache SSD dan kembangkan lebar jalur muat naik
Penyegerakan terbalik S3
Tulis terus ke S3 secara luaran
Fail awan baru tidak dapat dilihat pada titik pemasangan tempatan
Lakukan operasi cache refresh untuk menyegarkan cache metadata
Ikut sahaja
"Status Bil-> Dasar Kebenaran-> Rangkaian Masa-> Perkakasan/Cache Tempatan-> Sekatan Khas"
Urutan ini dibongkar secara beransur-ansur, kebanyakannya
Kegagalan penyegerakan AWS Storage Gateway dapat diselesaikan dalam masa yang singkat. Hanya dengan menjaga kebiasaan pengurusan dan pemantauan perakaunan awan yang baik, kita dapat memastikan operasi saluran paip data awan hibrid perusahaan yang stabil.