Amazon File Cache คืออะไร – พร้อมวิธีการใช้งาน

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

บทความนี้แปลมาจากบทความที่เป็นภาษาญี่ปุ่นที่ชื่อว่า [新サービス] Amazon File Cache が一般提供されました โดยเจ้าของบทความนี้คือ คุณ Shibata เป็นคนญี่ปุ่นครับ

เมื่อแปลจากภาษาญี่ปุ่นมาเป็นภาษาไทยแล้วผมได้เรียบเรียงเนื้อหาใหม่เพื่อให้เข้าใจง่ายขึ้น เนื่องจากบางครั้งอาจมีการอัปเดตข้อมูลใหม่ จึงมีความจำเป็นต้องอัปเดตให้เป็นข้อมูลปัจจุบัน


สวัสดีครับ ผม Shibata ครับ

Amazon File Cache เป็นบริการใหม่ที่เปิดตัวในงาน AWS Storage Day 2022 ที่จัดขึ้นในเดือนสิงหาคมปีนี้ ซึ่งได้รับการเผยแพร่อย่างเป็นทางการแล้ว

ดูการเปิดตัวจาก AWS ได้ที่ลิงก์ด้านล่างนี้

บทความนี้ได้อธิบายภาพรวมของ Amazon File Cache

Amazon File Cache คืออะไร

Amazon File Cache เป็นบริการที่ให้บริการ Cache server ที่ให้การ Cache ความเร็วสูงสำหรับ File server

(อ้างอิงรูปภาพจาก AWS Storage Day 2022 Keynote)

Amazon File Cache รองรับ File server ดังนี้

  • Amazon S3 Bucket
  • NFS Server ที่ให้บริการโดย AWS (สามารถเข้าถึง DNS ผ่าน NFS v3)
    • Amazon FSx for OpenZFS
    • Amazon FSx for NetApp ONTAP
  • NFS Server ของ On-premise Environment (NFS v3)

ประเด็นคือให้ความรู้สึกเหมือนเป็น Bucket หรือ NFS Server ของ NFS v3 แต่ไม่ได้ระบุไว้ว่ารองรับ Amazon EFS หรือไม่
(สำหรับ EFS ดูเหมือนว่าไม่มีทางเลือกนอกจากต้องสร้างสภาพแวดล้อมจริงและตรวจสอบการดำเนินการ...)

และ Client ที่สามารถใช้ Amazon File Cache ได้ ณ วันนี้คือ

เมื่ออ่าน Document ของ Amazon File Cache ดูแล้ว ทำให้พบว่าบริการนี้ได้รับการปรับแต่งตาม FSx for Lustre ทำให้มีเงื่อนไขเช่นเดียวกับ FSx for Lustre อยู่ในหลายๆที่

ดังนั้นดูเหมือนว่าจะต้องติดตั้ง Luster Client (Ver.2.12 หรือใหม่กว่า) บน Client ที่ใช้สำหรับครั้งนี้

Region ที่พร้อมใช้งาน

Region ที่พร้อมใช้งานสำหรับ Amazon File Cache ณ วันที่เขียนบทความมีดังนี้

  • US East (N. Virginia)
  • US East (Ohio)
  • US West (Oregon)
  • Canada (Central)
  • Europe (Frankfurt)
  • Europe (Ireland)
  • Europe (London)
  • Asia Pacific (Tokyo)
  • Asia Pacific (Singapore)
  • Asia Pacific (Sydney)

ราคา

ดูราคาได้ที่ลิงก์ด้านล่างนี้
Amazon File Cache Pricing

ค่าบริการ Amazon File Cache มีอยู่ 2 ประเภทหลักดังนี้

  • ค่าใช้จ่ายการใช้งาน Storage: ค่าใช้จ่ายขึ้นอยู่กับการใช้งาน Cache และ Metadata (หน่วย GB-months คิดตามหน่วยวินาที)
  • ปริมาณการถ่ายโอนข้อมูล: ค่าบริการในการถ่ายโอนข้อมูล "เข้า", "ออก" ในกรณีที่ข้าม AZ และ VPC Peering + ค่าบริการในการถ่ายโอนข้อมูล "ออก" ในกรณีที่ข้าม Region

จุดนี้ก็เหมือนกับ FSx for Lustre
แต่สำหรับจุดที่ต้องระวังคือ

  • Storage throughput ที่มีประสิทธิภาพสูงมากถึง 1000 MB/s ต่อ TiB
  • ปริมาณความจุ Storage ขั้นต่ำของ Amazon File Cache คือ 1.2 TiB (เช่นเดียวกับ FSx for Lustre)
  • ราคาต่อหน่วยการใช้ Storage สูงกว่า 2 เท่าของ FSx for Lustre ที่มีอัตราส่วนปริมาณงานเท่ากัน

แนะนำให้ประเมินราคาล่วงหน้าเมื่อมีการใช้งาน เนื่องจากค่าใช้จ่ายการใช้งาน Storage มีแนวโน้มที่จะราคาสูง

ตัวอย่างเช่น ราคา Storage ใน Region Singapore ของ ณ วันที่เขียนบทความ จะอยู่ที่ $1.506 per GB-month ทำให้ถึงแม้จะเลือกความจุขั้นต่ำสุดที่ 1.2TiB (1200GB) ก็ต้องจ่าย $1,807.19 *1ทุกๆเดือนสำหรับแค่ค่า Storage อย่างเดียว ซึ่งถือว่าค่อนข้างแพงเลยทีเดียว

จะมีค่าบริการในการถ่ายโอนข้อมูลเพิ่มเติมตามจริง

การทดสอบ

ครั้งนี้ เราจะมาสร้างสภาพแวดล้อม Cache สำหรับ S3 Bucket และตรวจสอบการทำงาน
ก่อนอื่นผมต้องการตรวจสอบขั้นตอนการใช้งาน ดังนั้นจะไม่ทำการประเมินประสิทธิภาพ

สร้างสภาพแวดล้อม S3 + Amazon File Cache และ EC2 Instance สำหรับตรวจสอบการเชื่อมต่อบน VPC ที่มีอยู่ใน Region Singapore บนบัญชี AWS ที่ใช้สำหรับการตรวจสอบ (Validate AWS account) ของเรา

เราจะใช้ Ubuntu 22.04 แทน Amazon Linux 2 เนื่องจาก Document ถือว่าเป็น Luster Client Ver.2.12 หรือใหม่กว่า
(อย่างไรก็ตาม เมื่อได้ตรวจสอบในภายหลังแล้ว ไม่ว่าจะเป็น Amazon Linux 2, Lustre Client Ver.2.10 ก็ไม่มี Error)

การเตรียม S3

ขั้นแรก ให้เตรียม S3 ก่อน
ครั้งนี้ เราจะมาสร้าง S3 Bucket ชื่อ amazon-file-cache-test-20230106 ใน Region Singapore

ซึ่งเป็น Bucket แบบ Private ที่มีการตั้งค่าน้อยที่สุด
และให้อัปโหลดไฟล์ (hello-world.txt) เพื่อใช้สำหรับทดสอบ

การเตรียม Security Group

Amazon File Cache ต้องตั้งค่า Security Group 1 ตัว เพื่อรับการสื่อสาร Inbound

โปรดทราบว่า Security Group นี้ ต้องเปิด Port Lustre (TCP 988, 1021 - 1023 และ UDP 988, 1021 - 1023) ไม่ใช่ Port NFS (TCP 2049, UDP 2049)

แล้วถ้าหากทำการตั้งค่า Security Group ไม่ถูกต้อง Error message ต่อไปนี้จะปรากฏขึ้นตอนสร้างสภาพแวดล้อม

The file cache cannot be created because the default security group in the subnet provided or the provided security groups do not permit Lustre LNET network traffic on port 988

การสร้าง Amazon File Cache

เราจะสร้าง Amazon File Cache ในขั้นตอนนี้

Amazon File Cache ถือเป็นส่วนหนึ่งของ Amazon FSx บน AWS Management Console
เลือก Caches ที่เมนูด้านซ้ายจากหน้าจอหลักของ Amazon FSx แล้วคลิก Create cache

Step 1 - Specify cache details
ขั้นแรกให้ระบุชื่อ Cache กับความจุของ Storage และระบุ Subnet ที่จะวาง Cache
ความจุของ Storage จะระบุระหว่าง 1.2 TiB - 2.4 TiB โดยเพิ่มขึ้นทีละ 1.2TiB หรือ 2.4TiB (2.4,4.8,7.2...) และ Throughput capacity จะถูกตั้งค่าโดยอัตโนมัติ *2ตามความจุ
การระบุ Subnet จะดำเนินการตามสภาพแวดล้อม และระบุสิ่งที่สร้างขึ้นก่อนหน้านี้ใน Security Group

Encryption (การเข้ารหัส) ของ Storage จำเป็นต้องมี
ครั้งนี้จะเลือก Encryption key ค่าเริ่มต้น

Step 2 - Link data repositories
เมื่อมาหน้านี้จะเป็นการตั้งค่าของ Cache source (Link data repositories)

มีช่องให้เลือก Repository เราสามารถเลือก NFS หรือ S3 ก็ได้
ครั้งนี้เราจะเลือก S3 และจะตั้งค่าเนื้อหาต่อไปนี้

  • Data repository path : Bucket URL s3://amazon-file-cache-test-20230106/
  • Cache path : Path ที่ต้องการ (ครั้งนี้คือ /s3test)

Amazon File Cache สามารถ Cache ได้จาก S3 Bucket หลายตัว และ Cache path คือ Path สำหรับแบ่ง Root ในขณะนั้น
เมื่อคลิกปุ่ม Add เนื้อหาที่ป้อนจะถูกเพิ่มลงในช่อง Data repository associations ที่ด้านบนหน้าจอ

Step 3 - Review and create
เมื่อเสร็จสิ้นการตั้งค่าที่จำเป็นแล้ว ให้ตรวจสอบเนื้อหาที่ป้อนก่อนหน้านี้เพื่อไม่ให้มีความผิดพลาด แล้วคลิก Create cache ด้านล่าง

การสร้าง Cache จะเริ่มต้นขึ้น ให้รอจนกว่าจะเสร็จสิ้น

ครั้งนี้เสร็จสิ้นในเวลาประมาณ 10 นาที

เมื่อเปิดหน้าจอรายละเอียด ก็จะแสดงเป็นแบบนี้
Cache type คือ Lustre version 2.12
เมื่อสร้าง Cache แล้ว จะมี DNS name ที่สามารถอ้างอิงจาก DNS (Route 53 Resolver) ของ VPC ได้ และชื่อนี้กับ Mount name จำเป็นสำหรับการใช้งานจาก Client

สำหรับแต่ละแท็บที่ด้านล่างของหน้าจอมีลักษณะดังนี้
อันแรก Network & security เป็นข้อมูลตำแหน่ง Network

ต่อไป Monitoring เราสามารถตั้งค่า CloudWatch alarms และตรวจสอบสถานะการทำงานได้ที่นี่

ต่อไป Administration เราสามารถเปลี่ยนเวลา Weekly maintenance window ได้ที่นี่

ต่อไป Data repositories มีลักษณะดังนี้ และข้อมูลของ Cache source repository จะแสดงขึ้นมา

สุดท้าย Tags คือช่อง Maintenance ของ Tag

นอกจากนี้ เมื่อคลิกปุ่ม Attach จะแสดงขั้นตอนการเชื่อมต่อจาก Client เป็น Pop-up ตามรูปภาพด้านล่าง

เพิ่มเติม: เกี่ยวกับ DNS name และ ENI

DNS name ถูกลงทะเบียนใน DNS (Route 53 Resolver) และเมื่อตรวจสอบเนื้อหาแล้ว Private IP จะถูกส่งกลับมาดังนี้
กรณีที่ต้องการใช้จากภายนอก VPC จะต้องมี Route 53 Resolver inbound endpoint เพราะไม่ใช่ public record

# สามารถตอบกลับได้จาก DNS ของ VPC เท่านั้น
$ dig fc-0a9573xxxxxxxxxxx.fsx.ap-southeast-1.amazonaws.com +short
192.168.11.141

นอกจากนี้ ด้วยเหตุผลบางอย่าง 5 ข้อ พอตรวจสอบดูแล้วผมคิดว่า "ควรมี ENI หนึ่งรายการสำหรับ Amazon File Cache" จากผลลัพธ์ข้างต้น

หนึ่งข้อที่ทราบคือเป็นสิ่งที่ใช้ใน DNS name แต่ไม่ทราบการนำไปใช้ของอีก 4 ข้อที่เหลือ
ตามที่คาดไว้ ผมคิดว่ามันอาจจะถูกใช้เพื่อเข้าถึง Cache source เมื่อใช้ NFS เป็น Cache source

การเตรียม EC2

เมื่อเตรียม Cache เสร็จแล้ว ต่อไปเรามาเตรียม EC2 กัน

เนื่องจากขั้นตอนของ Document ตามที่กล่าวมาข้างต้น ใช้ Ubuntu 22.04 ดังนั้นครั้งนี้จึงเตรียมสภาพแวดล้อม Ubuntu ตามนี้

ดูตัวอย่างการสร้าง Ubuntu บน EC2 ได้ที่ลิงก์ด้านล่างนี้ (ตัวอย่างนี้เป็นเวอร์ชัน 20.04 ตอนสร้างให้เลือกเวอร์ชัน 22.04 ซึ่งเป็นเวอร์ชันล่าสุด ณ วันที่เขียนบทความนี้)

เข้ามาที่ EC2 Instance ที่สร้างเสร็จแล้ว และทำการ Update kernel และติดตั้ง Lustre Client ตามขั้นตอนด้านล่างนี้

# กรณีของ Ubuntu 22.04
$ cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Ubuntu 22.04.1 LTS"

# การลงทะเบียน AWS Lustre client Ubuntu repository
wget -O - https://fsx-lustre-client-repo-public-keys.s3.amazonaws.com/fsx-ubuntu-public-key.asc | gpg --dearmor | sudo tee /usr/share/keyrings/fsx-ubuntu-public-key.gpg >/dev/null

sudo bash -c 'echo "deb [signed-by=/usr/share/keyrings/fsx-ubuntu-public-key.gpg] https://fsx-lustre-client-repo.s3.amazonaws.com/ubuntu jammy main" > /etc/apt/sources.list.d/fsxlustreclientrepo.list && apt-get update'

# กรณีที่ Kernel version เก่ากว่า 5.15.0.1020-aws ให้อัปเดต Kernel ก่อน
uname -r

# ครั้งนี้เป็น 5.15.0-1026-aws ดังนั้นไม่ต้องอัปเดต + รีสตาร์ท แต่ถ้าเก่ากว่า 5.15.0.1020-aws ให้อัปเดต + รีสตาร์ท ตามด้านล่างนี้
# ※Lustre Client ได้รับการติดตั้งพร้อมกับการอัปเดต Kernel
sudo apt install -y linux-aws lustre-client-modules-aws && sudo reboot

# กรณีที่อัปเดต + รีสตาร์ท ผลลัพธ์ 5.15.0-10xx-aws → อัปเดตเป็น 5.15.0-1026-aws


ยกเว้นมีการระบุ Kernel version เพื่อใช้ Lustre Client ซึ่งเป็นขั้นตอนง่ายๆ
ผลลัพธ์หลังการติดตั้งจะเป็นแบบนี้

# ตรวจสอบการทำงานเกี่ยวกับ Lustre
$ dpkg -l | grep lustre
ii  lustre-client-modules-5.15.0-1026-aws 2.12.8-1fsx6                            amd64        Lustre Linux kernel module (kernel 5.15.0-1026-aws)
ii  lustre-client-modules-aws             5.15.0.1026.24                          amd64        Lustre kernel modules for Amazon Web Services (AWS) systems.
ii  lustre-client-utils                   2.12.8-1fsx6                            amd64        Userspace utilities for the Lustre filesystem (client)

# ตรวจสอบ Version ที่ติดตั้ง
$ lfs --version
lfs 2.12.8

การตรวจสอบการเชื่อมต่อ

ต่อไปเรามาตรวจสอบการเชื่อมต่อกัน
รันคำส้่ง mount ในขั้นตอนถัดไปบนคอนโซล EC2

# (Optional) สร้าง mount directory
sudo mkdir -p /mnt

# รันคำสั่ง mount
sudo mount -t lustre -o relatime,flock fc-0a9573xxxxxxxxxxx.fsx.ap-southeast-1.amazonaws.com@tcp:/ms5xxxxx /mnt

การระบุคำสั่ง mount สามารถคัดลอกและวางสิ่งที่แสดงใน "Attach" ของ Management console ได้
เมื่ออธิบายตามแบบฟอร์มก็จะเป็นดังนี้

# ระบุ -t lustre และต้องเป็น DNS name และ Mount name
sudo mount -t lustre -o relatime,flock "DNS name"@tcp:/"mount name" "mount point"


คำสั่ง mount ถ้าเสร็จสิ้นโดยไม่มี Error ก็ถือว่าสำเร็จ
หลังจากนั้น ถ้าทำการเข้าถึง mount point (ครั้งนี้คือ /mnt/) ก็จะเข้าถึง Cache ได้อย่างโปร่งใส

# "Cache pass" แนบอยู่ใต้ mount point
$ ls /mnt/
s3test

# ภายใต้ Cache pass เป็น S3 Bucket และสามารถอ้างอิงไฟล์ที่มีอยู่ใน Bucket ได้
$ ls /mnt/s3test/
hello-world.txt

# สามารถอ้างอิงเนื้อหาในไฟล์ได้
$ cat /mnt/s3test/hello-world.txt 
Hello Amazon File Cache!


อย่างไรก็ตาม ผลลัพธ์ของคำสั่ง df จะเป็นแบบนี้

$ df
Filesystem                    1K-blocks    Used  Available Use% Mounted on
/dev/root                       7941576 1930584    5994608  25% /
tmpfs                            228328       0     228328   0% /dev/shm
tmpfs                             91332     824      90508   1% /run
tmpfs                              5120       0       5120   0% /run/lock
/dev/nvme0n1p15                  106858    5329     101529   5% /boot/efi
tmpfs                             45664       4      45660   1% /run/user/1000
192.168.11.141@tcp:/ms5jjbmv 1201382912   10240 1201370624   1% /mnt


ถ้าตั้งค่าสิทธิ์การเข้าถึงของ Directory ที่ mount แล้ว เราจะสามารถเขียนได้ตามปกติ

# ลืมตั้งค่าสิทธิ์การเข้าถึงที่เรียบง่าย...
# ※เดิมทีผมรู้สึกว่า mount -o rw ดีกว่า แต่เนื่องจากเป็นการตรวจสอบการทำงาน ดังนั้นก็จะทำตามนี้...
$ chmod 777 /mnt/s3test/

# ถ้าเรามีสิทธิ์ในการเขียน เราสามารถสร้างไฟล์ใหม่ได้ตามปกติ
$ sudo echo "write test" > /mnt/s3test/write-test.txt

# เราสามารถอ้างอิงจาก local ได้ทันที
$ cat /mnt/s3test/write-test.txt 
write test


อย่างไรก็ตาม ไฟล์ที่เขียนจะไม่ถูกปรับเปลี่ยนใน Cache source ในทันที และดูเหมือนว่าต้อง Export ด้วยคำสั่ง lfs hsm_archive
รันคำสั่ง lfs hsm_archive ในไฟล์ที่ต้องการและถ้าเสร็จสิ้นโดยไม่มี Error ไฟล์จะถูกเพิ่มไปยัง S3 Bucket

# Export ไฟล์ที่ต้องการไปยัง Cache source (S3 Bucket)
$ sudo lfs hsm_archive /mnt/s3test/write-test.txt 

# ตรวจสอบผลลัพธ์
$ sudo lfs hsm_state /mnt/s3test/write-test.txt 
/mnt/s3test/write-test.txt: (0x00000009) exists archived, archive_id:1

เพิ่มเติม: เกี่ยวกับเส้นทางการเข้าถึงไปยัง S3

ครั้งนี้เนื่องจากเป็น subnet ที่วาง Amazon File Cache ไว้ใน Private subnet ที่ปิดโดยสมบูรณ์ที่ไม่มีทั้ง NAT Gateway และ VPC Endpoint (Gateway) แต่เราก็สามารถใช้งานได้โดยไม่มีปัญหา
ดูเหมือนว่าการเข้าถึง S3 นั้นทำได้จากพื้นที่ AWS Managed

การลบ Cache

เนื่องจากการตรวจสอบการทำงานเสร็จแล้ว ก็จะลบ Cache ในตอนท้าย

เลือกไฟล์ Cache ที่ต้องการลบ แล้วคลิก Actions และเลือก Delete cache

แล้ว Pop-up ยืนยันจะแสดงขึ้นมา ให้ป้อน Cache ID แล้วคลิก Delete แล้วกระบวนการลบจะเริ่มขึ้น

ให้รอสักครู่จนกว่าจะลบออกเสร็จสมบูรณ์

อื่นๆ

การตรวจสอบการทำงานสิ้นสุดแล้ว แต่หลังจากที่ได้อ่าน Document แล้วอยากจะแนะนำบางจุดที่น่าสนใจ

1. กรณีที่ใช้ On-premises NFS server

ข้อกำหนดเบื้องต้นในกรณีที่ใช้ NFS server ของ On-premise environment เป็น Cache source มีอธิบายอยู่ในลิงก์ด้านล่าง

เมื่อเลือกบางประเด็นสำคัญจากที่นี่

  • ต้องเป็น NFS v3
  • การเข้าถึงฝั่ง On-premise ต้องเป็น Private network ที่สอดคล้องกับ RFC 1918
  • IP ที่สามารถเข้าถึงได้จาก Amazon File Cache และต้องเป็น Host name ที่สามารถจำแนกชื่อได้
  • On-premise environment และ VPC ต้องถูกเชื่อมต่อผ่าน Direct Connect หรือ Site-to-Site VPN

โปรดทราบว่า On-premise environment และ VPC จะต้องเชื่อมต่อกับ Private

2. Performance

บางทีทุกคนที่ดูบทความนี้ก็ต้องการทราบข้อมูลของ Performance ด้วย ดังนั้นผมจะแปะลิงก์ไว้ด้านล่างนี้

3. Maintenance window

Amazon File Cache ยังมี Weekly maintenance window เช่นเดียวกับ FSx series อื่นๆ

ตาม Document

Patching occurs infrequently, typically once every several weeks. Patching should require only a fraction of your 30-minute maintenance window. During these few minutes of time, your cache will be temporarily unavailable.

ระหว่างการ Maintenance ในช่วงเวลาไม่กี่นาทีนี้ ดูเหมือนว่าเราอาจจะไม่สามารถเข้าถึง Cache ได้

สุดท้ายนี้

ครั้งนี้ผมได้ทำการตรวจสอบการทำงานให้ดูเป็นตัวอย่าง
โดยส่วนตัวแล้วผมไม่มีสภาพแวดล้อมที่ดีและยากที่จะตรวจสอบ ดังนั้นผมจึงมอบความไว้างใจให้กับบริการ AWS

หมายเหตุ

  1. ประมาณ $60 ต่อ 1 วัน
  2. 1000MB/s ต่อ 1TiB

ผมหวังว่าบทความนี้จะเป็นประโยชน์ให้กับผู้อ่านได้นะครับ

แปลโดย: POP จากบริษัท Classmethod (Thailand) ครับ !

บทความต้นฉบับ