การเติมเงิน Amazon Cloud: เกตเวย์ไฟล์ AWS Storage Gateway ซิงโครไนซ์ไฟล์ในเครื่องเป็น S3คู่มือฉบับเต็มสำหรับการแก้ไขปัญหาที่ล้มเหลว

ในสถาปัตยกรรมคลาวด์แบบไฮบริด AWS S3 File Gateway (เกตเวย์ไฟล์) เป็นสะพานเชื่อมระหว่างห้องคอมพิวเตอร์ในพื้นที่ขององค์กรและที่เก็บข้อมูลบนคลาวด์ AWS อนุญาตให้แอปพลิเคชันภายในเครื่องเขียนไฟล์ลงในเกตเวย์ผ่านโปรโตคอล NFS หรือ SMB มาตรฐานจากนั้นเกตเวย์จะซิงโครไนซ์ไฟล์เหล่านี้ไปยังที่เก็บข้อมูล Amazon S3โดยอัตโนมัติ

อย่างไรก็ตามในการดำเนินการและการบำรุงรักษาจริงวิศวกรหลายคนจะพบ"

มีการเขียนไฟล์ในเครื่องแต่ไม่สามารถมองเห็นได้ใน S3

"หรือ"

เกตเวย์แจ้งข้อผิดพลาดการซิงโครไนซ์ถูกขัดจังหวะโดยตรง

"สถานการณ์ที่น่าอับอายคำถามแบบนี้ดูเหมือนง่ายแต่อาจเกี่ยวข้องกับ

การเรียกเก็บเงินบัญชีนโยบายการอนุญาตเวลาเครือข่ายดิสก์แคชภายในเครื่องและกฎ S3

และเหตุผลอื่นๆอีกมากมาย

บทความนี้รวบรวมประสบการณ์การใช้งานและการบำรุงรักษาบรรทัดแรกและรวบรวมชุดแนวคิดการตรวจสอบจากตื้นไปลึกเพื่อช่วยให้คุณค้นหาและแก้ปัญหาความล้มเหลวในการซิงโครไนซ์ Storage Gateway ได้อย่างรวดเร็ว

1.ขั้นตอนแรก: ตรวจสอบบริการพื้นฐานและสถานะบัญชี (หลักฐานที่ไม่สามารถละเลยได้)

ก่อนที่จะตรวจสอบเครือข่ายที่ซับซ้อนต่างๆและการกำหนดค่าสิทธิ์ก่อนอื่นเราต้องยืนยันความสมบูรณ์ของบัญชี AWS และบริการพื้นฐาน

1.ตรวจสอบสถานะบัญชี AWS และการเรียกเก็บเงิน

หลายทีมมักจะมองข้ามพื้นฐานที่สุดเมื่อตรวจสอบรายละเอียดทางเทคนิค

สถานะบัญชี

。หากทรัพยากรของบัญชี AWS ถูกระงับหรือจำกัดเนื่องจากการค้างชำระ (เช่นสิทธิ์การโทร API ถูกจำกัด) บริการพื้นหลังของ Storage Gateway จะไม่สามารถเขียนข้อมูลไปยัง S3ได้

ตรวจสอบ: ลงชื่อเข้าใช้คอนโซล AWS เพื่อดูว่ามีการเรียกเก็บเงินค้างหรือข้อความแจ้งการอายัดบัญชีบนอินเทอร์เฟซ Billing หรือไม่

คำแนะนำในการดำเนินการและการบำรุงรักษา: เมื่อปรับใช้สภาพแวดล้อมการผลิตบริษัทต่างๆจะต้องตรวจสอบให้แน่ใจว่าช่องทางการเติมเงินของบัญชี AWS เป็นไปอย่างราบรื่นและกำหนดค่าการแจ้งเตือนการเรียกเก็บเงิน CloudWatch (Billing Alerts) ในขณะเดียวกันขอแนะนำให้ผูกบัตรเครดิตที่มีอยู่หรือกรอกการเติมเงินบัญชี AWS และคำเตือนโควต้าผ่านตัวแทน AWS ที่เป็นไปตามข้อกำหนดเพื่อหลีกเลี่ยงการหยุดชะงักของช่องทางข้อมูลในพื้นที่ไปยังระบบคลาวด์เนื่องจากการค้างชำระอย่างกะทันหัน

2.ตรวจสอบสถานะการทำงาน Gateway กับ CloudWatch บันทึกสุขภาพ

ลงชื่อเข้าใช้คอนโซลของ AWS Storage Gateway เพื่อยืนยันว่าสถานะของ Gateway เป็น "ออนไลน์" (ออนไลน์) หรือไม่

ตรวจสอบว่าคุณได้เปิดใช้งาน CloudWatch Health Logs แล้วหรือไม่ข้อยกเว้นการซิงโครไนซ์หลายอย่างของเกตเวย์ไฟล์ (เช่น S3AccessDenied, GatewayClockOutOfSync เป็นต้น) จะถูกส่งออกโดยตรงในกลุ่มบันทึก CloudWatch ซึ่งเป็นพื้นฐานที่ตรงที่สุดสำหรับการวินิจฉัยปัญหา

2.ขั้นตอนที่2: การพิสูจน์ตัวตนและการตรวจสอบสิทธิ์ IAM

ไม่สามารถเขียนข้อมูลจากเกตเวย์ไปยัง S3ได้สาเหตุหนึ่งที่พบบ่อยที่สุดคือ

สิทธิ์ไม่เพียงพอ

。เกตเวย์ต้องผ่าน IAM Role (บทบาท) เพื่อ

3บาร์เรลสำหรับการอ่านและเขียน

[ท้องถิ่นลูกค้า NFS/SMB]

│ เขียน

▼

[เครื่องเสมือน AWS Storage Gateway]

│ การตรวจสอบตัวตนและลายเซ็นโดยใช้ IAM Role

▼

[Amazon S3ถังเก็บ]

1.ตรวจสอบนโยบายสิทธิ์ของ IAM Role (นโยบาย)

ตรวจสอบว่าเกตเวย์ผูก IAM Role มีสิทธิ์พื้นฐานต่อไปนี้สำหรับถังเก็บข้อมูล S3เป้าหมาย:

S3: GetBucketLocation (รับพื้นที่ถังเก็บ)

S3: ListBucket (รายการเนื้อหาถังเก็บ)

S3: GetObject (อ่านวัตถุ)

S3: PutObject (อัปโหลดไฟล์วัตถุ)

S3: PutObjectAcl (ถ้าเปิดการตั้งค่าที่เกี่ยวข้อง ACL)

2.ตรวจสอบ S3กลยุทธ์ถังเก็บ (Bucket Policy)

ยืนยันว่ามีการปฏิเสธอย่างชัดเจนในกลยุทธ์บาร์เรลหรือไม่ (

Deny

) คำสั่งตัวอย่างเช่น:

จำกัดการเข้าถึงเฉพาะ IP หรือ VPC และปิดกั้น IP ทางออกของเกตเวย์ไฟล์หรือไม่?

มีการเปิดใช้งานกลยุทธ์ในการบังคับส่ง HTTPs แต่การกำหนดค่าเกตเวย์ไม่ตรงกันหรือไม่

3.สิทธิ์คีย์การเข้ารหัส KMS (เช่น SSE-KMS เปิด)

หากถังเก็บข้อมูล S3เป้าหมายเปิดการเข้ารหัสคีย์ KMS แบบกำหนดเอง (SSE-KMS) IAM Role จะต้องไม่เพียงแต่มีสิทธิ์ S3เท่านั้น

KMS Key Policy

ได้รับสิทธิ์ต่อไปนี้ใน:

Kms: GenerateDataKey

Kms: Decrypt

การขาดสิทธิ์ KMS จะทำให้เกตเวย์โทร

PutObject

โยนโดยตรง

Access Denied

ข้อผิดพลาด

4. VPC Endpoint จำกัดกลยุทธ์

หากเกตเวย์และ S3สื่อสารผ่าน VPC Endpoint (VPC Endpoint) คุณต้องตรวจสอบว่า Endpoint Policy อนุญาตให้ IAM Role เข้าถึงเป้าหมาย S3ได้หรือไม่

3.ขั้นตอนที่3: การตรวจสอบการซิงโครไนซ์เวลาของเครือข่ายและระบบ

Storage Gateway มีข้อกำหนดที่สูงมากสำหรับการเชื่อมต่อเครือข่ายและความแม่นยำของเวลาของระบบภายใน

1.ระบบเวลาเบี่ยงเบน (GatewayClockOutOfSync)

AWS API อาศัยกลไกการขอลายเซ็นและลายเซ็นนั้นตรงเวลาหากเวลาของระบบของเครื่องเสมือน (VMware, Hyper-V หรือ EC2) ที่จัดเก็บเกตเวย์อยู่และเวลาของเซิร์ฟเวอร์ AWS

ค่าเบี่ยงเบนเกิน

5นาที

, AWS จะปฏิเสธคำขอทั้งหมดของเกตเวย์และส่งออกในบันทึก

GatewayClockOutOfSync

ผิด

วิธีการแก้ไขปัญหา: ลงชื่อเข้าใช้เกตเวย์ Local Console (Local Console) และตรวจสอบการกำหนดค่า NTP

วิธีแก้ไข: ตรวจสอบให้แน่ใจว่าเครื่องเสมือนเกตเวย์สามารถเชื่อมต่อกับเซิร์ฟเวอร์ NTP ได้ตามปกติ (เช่น0.amazon.pool.ntp.org หรือบริการ NTP ภายในองค์กร) หรือเปิดฟังก์ชันการซิงโครไนซ์เวลาของโฮสต์

2.ความราบรื่นของพอร์ตเครือข่ายขาออก

เกตเวย์จำเป็นต้องสร้างการเชื่อมต่อขาออกไปยังเซิร์ฟเวอร์ AWS ตรวจสอบว่าไฟร์วอลล์หรือกลุ่มรักษาความปลอดภัยไม่ได้บล็อกพอร์ตต่อไปนี้:

443 (HTTPS): พอร์ตการสื่อสารหลักระหว่างเกตเวย์และ AWS Storage Gateway และ S3。

80 (HTTP): จำเป็นเมื่อเปิดใช้งานเกตเวย์ (ขั้นตอนการเปิดใช้งานเท่านั้น)

22 (SSH/Support Channel): หากต้องการเปิดช่องการสนับสนุนทางเทคนิคอย่างเป็นทางการของ AWS

4.ขั้นตอนที่4: การแคชในพื้นที่และคอขวดทรัพยากรฮาร์ดแวร์

เกตเวย์ไฟล์ใช้สถาปัตยกรรม "Local Cache Backstage Asynchronous Upload" เมื่อปริมาณการเขียนในเครื่องมีมากหรือทรัพยากรฮาร์ดแวร์ไม่เพียงพอไฟล์จะอยู่ในแคชภายในเครื่องและไม่สามารถซิงโครไนซ์กับระบบคลาวด์ได้ทันเวลา

1.แคชข้อมูลสกปรกในสัดส่วนที่มากเกินไป (CachePercentDirty รายการตรวจสอบ)

เปิด CloudWatch Metrics และค้นหาเกตเวย์

CachePercentDirty

(เปอร์เซ็นต์ข้อมูลสกปรก) ตัวบ่งชี้

สถานะปกติ: เพิ่มขึ้นหลังจากเขียนข้อมูลและลดลงเหลือเกือบ0% หลังจากอัปโหลด

สถานะผิดปกติ: หาก CachePercentDirty สูงกว่า80% เป็นเวลานานแสดงว่าความเร็วในการเขียนของไคลเอนต์ในเครื่องนั้นเร็วกว่าความเร็วในการอัปโหลดเกตเวย์ไปยัง S3มาก

กลยุทธ์การรับมือ

:

ตรวจสอบว่าบรอดแบนด์ส่งออกเต็มหรือไม่และเพิ่มแบนด์วิดท์เครือข่ายหากจำเป็น

เพิ่มดิสก์แคชท้องถิ่นเพิ่มเติมสำหรับเกตเวย์

ควบคุมอัตราการเขียนบนไคลเอนต์เพื่อหลีกเลี่ยงไฟล์ขนาดใหญ่อย่างกะทันหันและบีบแคช

2.ดิสก์ท้องถิ่น I/O คอขวด (IoWaitPercent)

สังเกตใน CloudWatch

IoWaitPercent

ตัวชี้วัดหากค่ายังคงเกิน

10%

ซึ่งบ่งชี้ว่ามีปัญหาคอขวดในประสิทธิภาพการอ่านและเขียนของดิสก์แคชภายในเครื่อง (ตัวอย่างเช่นใช้ HDD ความเร็วต่ำแทน SSD/NVMe)

วิธีแก้ไข: ขอแนะนำให้แทนที่ดิสก์แคชด้วยฮาร์ดไดรฟ์โซลิดสเตต NVMe หรือ SSD ที่มี IOPS สูงหรือแยกดิสก์แคชขนาดใหญ่เดียวเป็นดิสก์ทางกายภาพอิสระหลายตัวและติดตั้งบนเครื่องเสมือนเพื่อกระจายความดัน I/O

3.สิทธิ์ของ Windows (ACL) รายการยาวเกินไป (Error 1344)

หากมีการแชร์ไฟล์ผ่านโปรโตคอล SMB เมื่อพยายามซิงค์มีความซับซ้อนเกินไป Win

ไฟล์ที่ตั้งค่าสิทธิ์ dows อาจถูกทริกเกอร์

Error: 1344 (0x00000540)

。

เหตุผล: AWS S3 File Gateway รองรับการจัดเก็บรายการควบคุมการเข้าถึง (ACEs) สูงสุด10รายการสำหรับแต่ละไฟล์หรือไดเรกทอรี

วิธีแก้ไข: ทำความสะอาดและปรับปรุงรายการสิทธิ์การเข้าถึง Windows สำหรับไฟล์หรือโฟลเดอร์รวมกลุ่มผู้ใช้และตรวจสอบให้แน่ใจว่าจำนวน ACE น้อยกว่า10

5.ขั้นตอนที่5: การเปลี่ยนแปลงของขั้ว S3ไม่ได้แสดงในเครื่อง (ความเข้าใจผิดเกี่ยวกับการรับรู้การซิงโครไนซ์ย้อนกลับ)

มีสถานการณ์พิเศษที่มักถูกเข้าใจผิดว่าเป็น "ความล้มเหลวในการซิงโครไนซ์":

ผู้ใช้อัปโหลดไฟล์โดยตรงบนคอนโซล S3แต่ไม่สามารถมองเห็นได้ในจุดเชื่อมต่อ NFS/SMB ในเครื่อง

。

หลักการ: เพื่อรักษาประสิทธิภาพสูงเกตเวย์ไฟล์จะแคชข้อมูลเมตาของ S3โดยค่าเริ่มต้นจะไม่สำรวจการเปลี่ยนแปลงภายในของถัง S3แบบเรียลไทม์

วิธีแก้ไข: รีเฟรชด้วยตนเอง: เลือกการแชร์ไฟล์ในคอนโซลคลิก "Refresh Cache" หรือเรียกใช้คำสั่ง refresh-cache ผ่าน AWS CLI การรีเฟรชอัตโนมัติ: กำหนดค่าช่วงเวลานโยบายการรีเฟรชแคชอัตโนมัติในการตั้งค่าการแชร์ไฟล์

หกตรวจสอบสรุป CheckList

หากคุณพบว่าการซิงโครไนซ์ไฟล์ของ AWS Storage Gateway ล้มเหลวคุณสามารถอ้างถึงตารางต่อไปนี้เพื่อตรวจสอบหมายเลขได้อย่างรวดเร็ว:

ระดับการสอบสวน

รายการตรวจสอบ

ปรากฏการณ์ทั่วไป/รหัสข้อผิดพลาด

โซลูชันที่แนะนำ

พื้นฐานและการเรียกเก็บเงิน

สถานะบัญชี AWS

การโทร API ถูกปฏิเสธเกตเวย์ออฟไลน์

เติมเงินในบัญชี AWS ให้ทันเวลาเพื่อให้แน่ใจว่าไม่มีการค้างชำระและกำหนดค่าคำเตือนยอดคงเหลือ

การควบคุมสิทธิ์

IAM Role/ S3 Policy / KMS

S3AccessDenied

กรอกสิทธิ์การถอดรหัส PutObject และ KMS

เวลาของระบบ

การประสานเวลา NTP

เกตเวย์นาฬิกาไม่ซิงค์

การสอบเทียบเครื่องเสมือนเกตเวย์เวลา NTP ให้แน่ใจว่าค่าเบี่ยงเบนน้อยกว่า5นาที

การเชื่อมต่อเครือข่าย

443พอร์ตกับ VPC Endpoint

เครือข่ายหมดเวลาการเชื่อมต่อล้มเหลว

ตรวจสอบกลุ่มความปลอดภัยและกฎทางออกไฟร์วอลล์

ประสิทธิภาพของฮาร์ดแวร์

แคชดิสก์กับ CPU/หน่วยความจำ

CachePercentDirty > 80%

อัปเกรดดิสก์แคช SSD และขยายแบนด์วิดท์การอัปโหลด

S3กลับซิงค์

ภายนอกเขียนโดยตรง S3

ไม่สามารถดูไฟล์ใหม่บนคลาวด์ได้ที่จุดเชื่อมต่อในเครื่อง

ดำเนินการ refresh-cache เพื่อรีเฟรชแคชข้อมูลเมตา

เพียงทำตาม

"สถานะการเรียกเก็บเงิน-> นโยบายสิทธิ์-> เครือข่ายเวลา-> ฮาร์ดแวร์ท้องถิ่น/แคช-> ข้อจำกัดพิเศษ"

ลำดับนี้ค่อยๆถูกถอดออกส่วนใหญ่

ความล้มเหลวในการซิงโครไนซ์ของ AWS Storage Gateway สามารถแก้ไขได้ในเวลาอันสั้นการรักษานิสัยการจัดการและการตรวจสอบบัญชีบนคลาวด์ที่ดีสามารถทำให้มั่นใจได้ว่าการทำงานของท่อส่งข้อมูลระบบคลาวด์แบบไฮบริดขององค์กรมีเสถียรภาพ