Blog AWS Indonesia

Membandingkan layanan storage untuk Kubernetes pada Amazon EKS

Seiring dengan meningkatnya adopsi container, ada kebutuhan mendasar yang semakin meningkat untuk saling berbagi data antara aplikasi tradisional monolith, aplikasi cloud-native, maupun microservices secara persistent. Ada beberapa opsi persistent storage dalam Kubernetes yang umum dipakai seperti local file system, Amazon Simple Storage Service (Amazon S3), shared file system, dan lainnya.

Memilih file system storage yang tepat merupakan hal penting, karena akan mempengaruhi performa dari aplikasi yang dibuat. Sebagai contoh penggunaan shared file system untuk task batch training AI/ML yang intensif pada Spark yang berjalan di cluster Kubernetes. Dengan pendekatan ini memungkinkan task training melakukan pengambilan dataset lebih cepat dan dapat menggunakan dataset yang berulang dalam file system, dan menghindari biaya request Amazon S3 yang berulang.

Dalam artikel ini, kita akan mempelajari bersama tentang perbandingan integrasi dan performa aplikasi Kubernetes dengan Amazon Elastic Kubernetes Service (Amazon EKS) dengan beberapa layanan persistent storage shared file system di AWS: Amazon Elastic File System (Amazon EFS), Amazon FSx for NetApp ONTAP, dan Amazon FSx for Lustre. Sehingga, Anda akan dapat memilih layanan file system yang tepat sesuai dengan kebutuhan dan skala aplikasi container Anda.

Amazon EKS adalah managed-service untuk menjalankan Kubernetes di AWS dan data center on-premises. Kubernetes adalah open-source container orchestration tool untuk melakukan scaling, deployment, dan manajemen aplikasi berbasis container. Banyak aplikasi Kubernetes memerlukan sistem storage yang terintegrasi dengan Kubernetes Container Storage Interface (CSI) untuk membuat file dan blok volume, scaling storage, melakukan snapshot, dan cloning.

Amazon EFS adalah managed-service shared storage yang bersifat serverless dan elastic yang disediakan oleh AWS. Sementara, FSx for NetApp ONTAP dan FSx for Lustre adalah managed-service shared storage yang dibangun di atas berbagai file system performa tinggi.

Artikel ini berasumsi bahwa Anda sudah memiliki pengalaman terhadap teknologi Kubernetes dan container. Bila Anda ingin mempelajarinya terlebih dahulu, Anda bisa menuju halaman web Kubernetes di AWS.

Gambaran Solusi

Untuk mendapatkan perbandingan definitif dan objektif, kita akan melakukannya di atas arsitektur dengan komponen sebagai berikut:

  • Cluster Amazon EKS dengan 2x worker nodes Amazon Elastic Compute Cloud (Amazon EC2) tipe instance c4.2xlarge.
  • File storage Amazon EFS, General purpose, throughput mode Elastic.
  • File system FSx for ONTAP, Multi-AZ, storage capacity 1024 GiB, throughput capacity 512 MB/s.
  • File system FSx for Lustre, Multi-AZ, storage capacity 1200 GiB, throughput per unit of storage: 500 MB/s/TiB.

Sebagai standar integrasi pada Amazon EKS, driver CSI memungkinkan Anda untuk menghubungkan sistem storage ke workload container sebagai storage yang persistent. Untuk integrasi Amazon EKS dengan berbagai alternatif layanan storage, kita akan menggunakan driver CSI untuk Amazon EFS, driver CSI untuk FSx for Lustre, dan driver NetApp Trident CSI dengan konfigurasi Multi-AZ. Kita akan bereksplorasi tentang bagaimana kita dapat melakukan provisioning volume dan Storage Class dengan pertimbangan performanya terhadap kebutuhan aplikasi Anda.

Pada akhir artikel ini, Anda akan memiliki pemahaman tentang pemilihan arsitektur untuk menilai penerapan deployment yang cocok menggunakan cluster Amazon EKS dengan Amazon EFS, FSx for ONTAP, atau FSx for Lustre.

Metodologi Tes

Tes kinerja akan dilakukan mengikuti skenario sebagai berikut:

Skenario tes:

  • Random read/write ops dengan proporsi 50% read dan 50% write
  • Access pattern dengan block size 1 MB
  • iodepth 64
  • Tes file 8 GB
  • 4 parallel jobs
  • Runtime 30 detik

Bila Anda ingin melakukan sendiri benchmark ini, hasil test mungkin akan memiliki hasil yang bervariasi dibandingkan dengan artikel ini. Hal ini dikarenakan berbagai variable lain yang mungkin berbeda dan tidak dibahas dalam artikel ini, seperti konfigurasi testing tool, konfigurasi storage, detil konfigurasi Cluster Amazon EKS dan lain nya.

Berkaitan dengan kondisi production, apapun solusi yang sudah Anda desain dan implementasi tidak akan berarti atau teruji sebelum Anda melakukan tes terhadap performanya. Dalam hal ini, kita dapat melakukan tes performa layanan storage Amazon EFS, FSx for ONTAP, dan FSx for Lustre dari pod Amazon EKS menggunakan tools fio (Flexible I/O), sebuah tool benchmarking storage. Karena uji coba Flexible IO Tester (FIO) menggunakan fungsi random read-write, untuk menyederhanakan hasil akhirnya, kita akan menghitung rata-rata dari sejumlah uji coba read dan write.

Metrik uji yang akan kita pantau adalah nilai rata-rata (average) throughput read & write.

Prasyarat

Untuk mengikuti langkah-langkah pada artikel ini, diperlukan prasyarat sebagai berikut:

  • Akun AWS. Jika Anda belum memiliki akun AWS, Anda dapat membuat akun AWS baru.
  • Pengetahuan mendasar tentang Kubernetes di AWS. Bila Anda ingin mempelajarinya terlebih dahulu, Anda bisa menuju halaman web Kubernetes di AWS.

Integrasi dan Tes Performa Amazon EKS dengan Amazon EFS

Dalam skenario ini, kami menggunakan region AWS di Singapore (ap-southeast-1) dan akan membuat deployment file system storage Amazon EFS dengan integrasi driver CSI yang berjalan di atas cluster Amazon EKS yang berada pada Availability Zone yang sama ( ap-southeast-1a ) di mana selanjutnya kami akan melakukan proses simulasi performa data dengan menggunakan tools fio.

Langkah #1: Lakukan instalasi driver CSI sesuai panduan berikut.

Langkah #2: Berikut perintah untuk membuat storage class Amazon EFS, persistent volume, persistent volume claim, dan melakukan static provisioning pod dengan menggunakan konfigurasi file YAML di bawah ini:

efs-storage-class.yaml

apiVersion: storage.k8s.io/v1
 kind: StorageClass
 metadata:
  name: efs-sc
 provisioner: efs.csi.aws.com

efs-pv.yaml

apiVersion: v1
 kind: PersistentVolume
 metadata:
  name: efs-pv
 spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  storageClassName: efs-sc
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: efs.csi.aws.com
    volumeHandle: fs-0cde002de786cd67f

efs-pv-claim.yaml

apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
  name: efs-claim
 spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: efs-sc
  resources:
    requests:
      storage: 10Gi

efs-pod.yaml

apiVersion: v1
 kind: Pod
 metadata:
  name: efs-app
 spec:
  containers:
  - name: app
    image: nginx
    ports:
      - containerPort: 80
        name: "http-server"
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: efs-claim

Jalankan perintah berikut untuk melakukan deployment berdasarkan file konfigurasi di atas:

kubectl apply -f efs-storageclass.yaml
kubectl apply -f efs-pv-claim.yaml
kubectl apply -f efs-pod.yaml

Langkah #3: Login ke dalam container:

kubectl exec -it efs-app  -- /bin/bash

Langkah #4: Setelah login ke dalam container, kita lanjutkan dengan melakukan update repository dan install tool fio

apt-get update
apt-get install fio -y

Langkah #5: Jalankan tes dengan perintah berikut:
Catatan: jangan lupa untuk masuk ke dalam directory sesuai dengan lokasi mount path yang telah dikonfigurasi pada file YAML sebelumnya.

cd /data
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=fiotest --filename=testfio --bs=1MB --iodepth=64 --size=8G --readwrite=randrw --rwmixread=50 --numjobs=4 --group_reporting --runtime=30

Hasil tes performa – Amazon EKS & Amazon EFS
Berikut adalah informasi output dari hasil tes terhadap integrasi Amazon EKS dan Amazon EFS dengan menggunakan block size sebesar 1 MB:

root@efs-app:/data# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=fiotest --filename=testfio --bs=1MB --iodepth
 =64 --size=8G --readwrite=randrw --rwmixread=50 --numjobs=4 --group_reporting --runtime=30
 fiotest: (g=0): rw=randrw, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=libaio, iodepth=64
 ...
 fio-3.33
 Starting 4 processes
 Jobs: 4 (f=4): [m(4)][21.1%][r=104MiB/s,w=110MiB/s][r=104,w=110 IOPS][eta 01m:56s] 
 fiotest: (groupid=0, jobs=4): err= 0: pid=762: Sun Nov 26 07:03:33 2023

  read: IOPS=110, BW=111MiB/s (116MB/s)(3485MiB/31456msec)
   bw (  KiB/s): min=26624, max=172032, per=98.41%, avg=111649.03, stdev=6523.62, samples=248
   iops        : min=   26, max=  168, avg=109.03, stdev= 6.37, samples=248
  write: IOPS=116, BW=117MiB/s (123MB/s)(3675MiB/31456msec); 0 zone resets
   bw (  KiB/s): min=49152, max=182272, per=97.41%, avg=116537.81, stdev=6748.15, samples=248
   iops        : min=   48, max=  178, avg=113.81, stdev= 6.59, samples=248
  cpu          : usr=0.09%, sys=0.59%, ctx=6873, majf=0, minf=31
  IO depths    : 1=0.1%, 2=0.1%, 4=0.2%, 8=0.4%, 16=0.9%, 32=1.8%, >=64=96.5%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=99.9%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=3485,3675,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64
 Run status group 0 (all jobs):
   READ: bw=111MiB/s (116MB/s), 111MiB/s-111MiB/s (116MB/s-116MB/s), io=3485MiB (3654MB), run=31456-31456msec
   WRITE: bw=117MiB/s (123MB/s), 117MiB/s-117MiB/s (123MB/s-123MB/s), io=3675MiB (3854MB), run=31456-31456msec

Berdasarkan hasil tes di atas, dapat kita simpulkan bahwa tes berhasil dilakukan dengan hasil READ 116 MB/s , WRITE 123 MB/s .

Integrasi dan Tes Performa Amazon EKS dengan FSx for ONTAP

Dalam skenario ini, kita menggunakan region AWS di Singapore (ap-southeast-1) dan akan membuat deployment file system storage FSx for ONTAP dengan integrasi driver CSI yang berjalan di atas cluster Amazon EKS yang berada pada Availability Zone yang sama ( ap-southeast-1a ) di mana selanjutnya kita akan melakukan proses simulasi performa data dengan menggunakan tools fio.

Langkah #1: Lakukan instalasi driver CSI sesuai panduan berikut.

Langkah #2: Berikut konfigurasi dan perintah untuk membuat storage class, persistent volume claim, dan provisioning pod menggunakan konfigurasi file YAML di bawah ini:
storage-class-csi-nas.yaml

apiVersion: storage.k8s.io/v1
 kind: StorageClass
 metadata:
 name: trident-csi
 provisioner: csi.trident.netapp.io
 parameters:
 backendType: "ontap-nas"
 fsType: "ext4"
 allowVolumeExpansion: True
 reclaimPolicy: Retain

fsxn-pod.yaml

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: task-trident-nas-pv-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 15Gi
  storageClassName: trident-csi
---
kind: Pod
apiVersion: v1
metadata:
  name: fsxn-pv-pod
spec:
  volumes:
    - name: task-trident-nas-pv-storage
      persistentVolumeClaim:
        claimName: task-trident-nas-pv-claim
  containers:
    - name: task-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts: # konfigurasi path mounting file system
        - mountPath: "/usr/share/trident-fsxn/"
          name: task-trident-nas-pv-storage
  nodeSelector: # segmen ini diperlukan agar pods di-deploy pada AZ yang sama
    topology.ebs.csi.aws.com/zone: ap-southeast-1a

Jalankan perintah berikut untuk melakukan deployment berdasarkan file konfigurasi di atas:

kubectl apply -f storage-class-csi-nas.yaml
kubectl apply -f fsxn-pod.yaml

Langkah #3: Login ke dalam container:

kubectl exec -it fsxn-pv-pod -- /bin/bash

Langkah #4: Setelah login ke dalam container, kita lanjutkan dengan melakukan update repository dan install tool fio

apt-get update
apt-get install fio -y

Langkah #5: Jalankan tes dengan perintah berikut:
Catatan: jangan lupa untuk masuk ke dalam directory sesuai dengan lokasi mount path yang telah dikonfigurasi pada file YAML sebelumnya.

cd /usr/share/trident-fsxn/
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=fiotest --filename=testfio --bs=1MB --iodepth=64 --size=8G --readwrite=randrw --rwmixread=50 --numjobs=4 --group_reporting --runtime=30

Hasil tes performa – Amazon EKS & FSx for ONTAP
Berikut adalah informasi output dari hasil tes terhadap integrasi Amazon EKS dan FSx for ONTAP dengan menggunakan block size sebesar 1 MB:

root@fsxn-pv-pod:/# cd /usr/share/trident-fsxn
root@fsxn-pv-pod:/usr/share/trident-fsxn# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=fiotest --filename=testfio --bs=1MB --iodepth=64 --size=8G --readwrite=randrw --rwmixread=50 --numjobs=4 --group_reporting --runtime=30
fiotest: (g=0): rw=randrw, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=libaio, iodepth=64
...
fio-3.33
Starting 4 processes
Jobs: 4 (f=4): [m(4)][23.5%][r=127MiB/s,w=141MiB/s][r=127,w=141 IOPS][eta 01m:41s] 
fiotest: (groupid=0, jobs=4): err= 0: pid=817: Sun Nov 26 07:00:17 2023
  read: IOPS=123, BW=123MiB/s (129MB/s)(3863MiB/31400msec)
   bw (  KiB/s): min=22528, max=251904, per=97.96%, avg=123408.52, stdev=11862.79, samples=248
   iops        : min=   22, max=  246, avg=120.52, stdev=11.58, samples=248
  write: IOPS=129, BW=129MiB/s (136MB/s)(4065MiB/31400msec); 0 zone resets
   bw (  KiB/s): min=30720, max=284672, per=98.18%, avg=130147.10, stdev=13764.41, samples=248
   iops        : min=   30, max=  278, avg=127.10, stdev=13.44, samples=248
  cpu          : usr=0.10%, sys=1.13%, ctx=7888, majf=0, minf=27
  IO depths    : 1=0.1%, 2=0.1%, 4=0.2%, 8=0.4%, 16=0.8%, 32=1.6%, >=64=96.8%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=99.9%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=3863,4065,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=123MiB/s (129MB/s), 123MiB/s-123MiB/s (129MB/s-129MB/s), io=3863MiB (4051MB), run=31400-31400msec
  WRITE: bw=129MiB/s (136MB/s), 129MiB/s-129MiB/s (136MB/s-136MB/s), io=4065MiB (4262MB), run=31400-31400msec

Berdasarkan hasil tes di atas, dapat kita simpulkan bahwa tes berhasil dilakukan dengan hasil READ 129 MB/s , WRITE 136 MB/s .

Integrasi dan Tes Performa Amazon EKS dengan FSx for Lustre

Dalam skenario ini, kita menggunakan region AWS di Singapore (ap-southeast-1) dan akan membuat deployment file system storage FSx for Lustre dengan integrasi driver CSI, lalu selanjutnya kita akan melakukan proses simulasi performa data dengan menggunakan tools fio.

Langkah #1: Lakukan instalasi driver CSI FSx for Lustre dengan mengikuti panduan di halaman berikut.

Langkah #2: Berikut contoh dan perintah untuk membuat storage class, persistent volume claim, dan melakukan provisioning pod dengan menggunakan konfigurasi file di bawah ini:

fsxL-storage-class.yaml

---
 kind: StorageClass
 apiVersion: storage.k8s.io/v1
 metadata:
    name: fsx-sc
 provisioner: fsx.csi.aws.com
 parameters:
    subnetId: YOUR_SUBNET_ID
    securityGroupIds: YOUR_SECURITY_GROUP_ID
    s3ImportPath: s3://YOUR_S3_BUCKET
    s3ExportPath: s3://YOUR_S3_BUCKET/export
    autoImportPolicy: NEW_CHANGED_DELETED
    deploymentType: PERSISTENT_1
    perUnitStorageThroughput: "50"
 mountOptions:
    - flock

Ganti YOUR_SUBNET_ID, YOUR_SECURITY_GROUP_ID, dan YOUR_S3_BUCKET sesuai dengan milik Anda sendiri.

fsxl-claim.yaml

apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
  name: fsx-claim
 spec:
  accessModes:
    - ReadWriteMany
  storageClassName: fsx-sc
  resources:
    requests:
      storage: 1000Gi

fsxl-pod-performance.yaml

kind: Pod
 apiVersion: v1
 metadata:
  name: fsxl-performance
 spec:
  containers:
    - name: fsxl-performance
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - name: persistent-storage
          mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: fsx-claim
  nodeSelector:
    topology.ebs.csi.aws.com/zone: ap-southeast-1b

Jalankan perintah berikut untuk melakukan deployment berdasarkan file konfigurasi di atas:

kubectl apply -f fsxL-storage-class.yaml
kubectl apply -f fsxl-claim.yaml
kubectl apply -f fsxl-pod-performance.yaml

Langkah #3: Login ke dalam container:

kubectl exec -it fsxl-performance  -- /bin/bash

Langkah #4: Setelah login ke dalam container, kita lanjutkan dengan melakukan update repository dan install tool fio

apt-get update
apt-get install fio -y

Langkah #5: Jalankan tes dengan perintah berikut:
Catatan: jangan lupa untuk masuk ke dalam directory sesuai dengan lokasi mount path yang telah dikonfigurasi pada file YAML sebelumnya.

cd /data/
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=fiotest --filename=testfio --bs=1MB --iodepth=64 --size=8G --readwrite=randrw --rwmixread=50 --numjobs=4 --group_reporting --runtime=30

Hasil tes performa – Amazon EKS & FSx for Lustre
Berikut hasil tes performa terhadap integrasi Amazon EKS dan FSx for Lustre dengan menggunakan block size 1 MB:

root@fsxl-performance:/data/# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=fiotest --filename=testfio8gb --bs=1MB --iodepth=64 --size=8G --readwrite=randrw --rwmixread=50 --numjobs=4 --group_reporting --runtime=30
fiotest: (g=0): rw=randrw, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=libaio, iodepth=64
 ...
 fio-3.33
 Starting 4 processes
 fiotest: Laying out IO file (1 file / 8192MiB)
 Jobs: 4 (f=4): [m(4)][100.0%][r=233MiB/s,w=212MiB/s][r=233,w=212 IOPS][eta 00m:00s]
 fiotest: (groupid=0, jobs=4): err= 0: pid=727: Sun Nov 26 06:49:44 2023
  read: IOPS=229, BW=230MiB/s (241MB/s)(6946MiB/30201msec)
   bw (  KiB/s): min=157696, max=327680, per=99.73%, avg=234882.02, stdev=10030.09, samples=234
   iops        : min=  154, max=  320, avg=229.38, stdev= 9.80, samples=234
  write: IOPS=240, BW=240MiB/s (252MB/s)(7254MiB/30201msec); 0 zone resets
   bw (  KiB/s): min=165888, max=346112, per=100.00%, avg=246250.16, stdev=9425.37, samples=234
   iops        : min=  162, max=  338, avg=240.48, stdev= 9.20, samples=234
  cpu          : usr=0.27%, sys=4.28%, ctx=21083, majf=0, minf=28
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.2%, 16=0.5%, 32=0.9%, >=64=98.2%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=6946,7254,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64
 Run status group 0 (all jobs):
  READ: bw=230MiB/s (241MB/s), 230MiB/s-230MiB/s (241MB/s-241MB/s), io=6946MiB (7283MB), run=30201-30201msec
  WRITE: bw=240MiB/s (252MB/s), 240MiB/s-240MiB/s (252MB/s-252MB/s), io=7254MiB (7606MB), run=30201-30201msec

Berdasarkan hasil tes di atas, dapat kita simpulkan bahwa tes berhasil dilakukan dengan hasil READ 241 MB/s , WRITE 252 MB/s .

Rangkuman Hasil Tes Performa

Tabel di bawah menunjukkan nilai rata-rata perbandingan kinerja opsi penyimpanan file sistem dalam aplikasi container Amazon EKS, dengan sampling file size 8 GB dan block size 1MB. Untuk merangkum, ini adalah spesifikasi yang dikonfigurasi untuk setiap tipe penyimpanan: Amazon EFS dengan general purpose throughput mode bursting; file system FSx for ONTAP, Multi-AZ, kapasitas storage 1024 GiB, kapasitas throughput 512 MB/s; dan file system FSx for Lustre, Multi-AZ, kapasitas storage 1024 GiB, throughput per unit of storage: 50 MB/s/TiB. Karena uji coba FIO menggunakan fungsi random read-write, untuk menyederhanakan hasilnya kami menghitung rata-rata dari sejumlah uji coba read dan write dengan hasil sebagai berikut:

Amazon EKS dan Amazon EFS

Amazon EFS dengan konfigurasi general purpose bursting adalah opsi penyimpanan file untuk container Amazon EKS yang seimbang. Amazon EFS berfungsi sebagai managed-service shared file system untuk container dalam cluster Amazon EKS dan menawarkan kinerja yang memadai untuk aplikasi yang tidak membutuhkan throughput yang banyak. Hal ini cocok untuk berbagai jenis penggunaan di mana kinerja file system yang konsisten dan moderat sudah cukup, karena memberikan keseimbangan antara efisiensi biaya dan kinerja. Saat memanfaatkan Amazon EFS di Amazon EKS dengan tingkat kinerja sedang, Anda dapat memperoleh manfaat dari:

  1. Kinerja Sedang: Tier general purpose bursting memberikan throughput dan latency yang baik, cocok untuk aplikasi yang membutuhkan kinerja yang handal namun tidak dalam kelas teratas.
  2. Efisiensi Biaya: Tier general purpose bursting menawarkan keseimbangan antara kinerja dan biaya, menjadikannya pilihan menarik untuk beban kerja yang tidak membutuhkan karakteristik kinerja tinggi. Biaya yang digunakan juga sesuai jumlah storage yang dipergunakan (pay-per-use).
  3. Scalability dan Fleksibilitas: Kapasitas Amazon EFS secara otomatis dapat ditingkatkan sesuai kebutuhan penyimpanan, memungkinkan ekspansi yang lancar saat request meningkat dalam lingkungan Amazon EKS.
  4. Managed-service: Amazon EFS menyederhanakan pengelolaan penyimpanan file untuk container di Amazon EKS dan mengurangi beban administratif.

Amazon EKS dan FSx for ONTAP

Anda dapat mempertimbangkan menggunakan skenario deployment Amazon EKS dengan FSx for ONTAP bila Anda memiliki kebutuhan untuk menjalankan aplikasi container yang membutuhkan skalabilitas tinggi, dukungan untuk multi-protocol file dan block storage, high availability dengan deployment multi-AZ, dan proteksi data dan fitur disaster recovery secara native. Pertimbangan yang akan mempengaruhi performa IOPS pada file system FSx for ONTAP pada skenario ini adalah bagaimana aplikasi container Anda pada cluster Amazon EKS mengakses storage FSx for ONTAP pada mount-point terkait. Anda juga bisa mendapatkan performa latency sub-millisecond dengan FSx for ONTAP di atas Amazon EKS.

FSx for ONTAP menggunakan model bayar sesuai penggunaan, yang berarti Anda hanya perlu membayar sumber daya yang digunakan, tanpa biaya awal atau biaya tambahan. Penggunaan Anda dihitung setiap jam dan kemudian diambil rata-rata bulanan untuk penagihan biaya. Untuk storage dan pengelolaan data, enam komponen FSx for ONTAP harus dipertimbangkan: storage SSD, IOPS SSD, kapasitas pool, kapasitas throughput, backup, dan lisensi SnapLock.

Amazon EKS dan FSx for Lustre

Anda dapat mempertimbangkan menggunakan skenario deployment Amazon EKS dengan FSx for Lustre bila Anda memiliki kebutuhan untuk menjalankan aplikasi container yang membutuhkan performa tinggi. Dengan driver CSI untuk FSx for Lustre, Anda bisa mendapatkan integrasi dengan container yang mudah dan cepat. FSx for Lustre cocok untuk digunakan pada aplikasi container yang membutuhkan latency rendah dan bandwidth throughput yang tinggi (dengan asumsi operasi block size yang tinggi – contoh 1 MB).

Menggunakan FSx for Lustre berarti Anda hanya dibebankan untuk sumber daya yang digunakan tanpa ada biaya minimum. Penggunaan Anda akan dihitung per detik, dan Anda akan ditagih untuk penggunaan rata-rata selama sebulan. Faktor penentu harga meliputi storage yang diproyeksikan, backup, kompresi data, dan ukuran transfer data.

Kesimpulan

Kami telah mendemonstrasikan bagaimana Anda dapat melakukan integrasi Amazon EKS dan menyediakan satu layanan data dengan performa tinggi menggunakan beberapa alternatif dari Amazon EFS, FSx for ONTAP, atau FSx for Lustre sesuai dengan kebutuhan dan skala aplikasi Anda. Besarnya throughput yang bisa dipacu terhadap deployment Amazon EFS, file system FSx for ONTAP, ataupun FSx for Lustre tergantung pada konfigurasi layanan terkait seperti pengaturan kapasitas throughput, konfigurasi kapasitas storage, dan sifat workload Anda.

Pemilihan opsi di antara Amazon EFS, FSx for ONTAP, FSx for Lustre, dan konfigurasinya tergantung pada pola akses file aplikasi, pertimbangan biaya, dan kebutuhan kinerja.

Amazon EFS cocok untuk aplikasi yang membutuhkan performa medium seperti general use case. Customer dapat memanfaatkan fitur managed-service dan serverless. Namun Amazon EFS hanya dapat digunakan oleh aplikasi berbasis linux. Biaya untuk opsi Amazon EFS masuk ke dalam kategori rendah ke medium dengan kapasitas storage minimum yang rendah sebesar 1GB dibandingkan opsi lain.

FSx for ONTAP cocok untuk aplikasi yang membutuhkan performa medium-tinggi. Customer dapat memanfaatkan fitur multi-protocol, Native DR, Snaplock serta kompatibilitas multi Operating System (Windows dan Linux). Biaya untuk opsi FSx for ONTAP masuk ke dalam kategori medium-tinggi dengan kapasitas storage minimum sebesar 1024 GB.

FSx for Lustre cocok untuk aplikasi yang membutuhkan performa tinggi. Namun customer hanya bisa menggunakan opsi ini untuk aplikasi berbasis Linux. Biaya untuk opsi FSx for Lustre masuk ke dalam kategori medium dengan ukuran storage minimum sebesar 1200 GB.

Bila Anda ingin mempelajari konsep yang dibahas pada artikel ini secara menyeluruh, Anda bisa menuju halaman panduan web Kubernetes di AWS, Amazon EFS dan Amazon FSx.

Pugar Jayanegara

Pugar Jayanegara

Pugar adalah seorang Senior Solution Architect di AWS dengan keahlian khusus dalam container, di mana ia membantu pelanggan untuk mentransformasi bisnis mereka. Sebelum bergabung dengan AWS, ia bekerja di berbagai perusahaan teknologi dan cloud utama dengan peran senior solution architect dalam integrasi sistem dan pengembangan software. Ia antusias dalam mengeksplorasi teknologi baru, membangun solusi kreatif & efektif untuk pelanggan dan mitra.

Felix Ricky

Felix Ricky

Felix Ricky adalah seorang Senior Solution Architect di AWS dengan keahlian khusus dalam storage system. Dia memiliki pengalaman selama 17 tahun di industri IT dan memiliki semangat yang kuat untuk transformasi digital perusahaan serta storage system. Di waktu luangnya, dia senang untuk mengikuti perkembangan teknologi terbaru di ranah cloud computing.