Memecahkan masalah berbagi file - AWSStorage Gateway

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Memecahkan masalah berbagi file

Anda dapat menemukan informasi berikut tentang tindakan yang harus dilakukan jika Anda mengalami masalah tak terduga dengan berbagi file Anda.

Berbagi file Anda terjebak dalam status MENCIPTAKAN

Ketika berbagi file Anda sedang dibuat, statusnya adalah MENCIPTAKAN. Status transisi ke status TERSEDIA setelah berbagi file dibuat. Jika berbagi file Anda terjebak dalam status MENCIPTAKAN, lakukan hal berikut:

  1. Buka konsol Amazon S3 di https://console.aws.amazon.com/s3/.

  2. Pastikan bucket S3 yang Anda petakan berbagi file Anda ada. Jika bucket tidak ada, buatlah. Setelah membuat bucket, status share file akan TERSEDIA. Untuk informasi tentang cara membuat bucket S3, lihatBuat emberdiPanduan Pengguna Amazon Simple Storage Service.

  3. Pastikan nama bucket Anda mematuhi aturan untuk penamaan bucket di Amazon S3. Untuk informasi selengkapnya, lihatAturan penamaan bucketdiPanduan Pengguna Amazon Simple Storage Service.

  4. Pastikan peran IAM yang Anda gunakan untuk mengakses bucket S3 memiliki izin yang benar dan memverifikasi bahwa bucket S3 terdaftar sebagai sumber daya dalam kebijakan IAM. Untuk informasi selengkapnya, lihat Memberikan akses ke bucket Amazon S3.

Anda tidak dapat membuat berbagi file

  1. Jika Anda tidak dapat membuat berbagi file karena berbagi file Anda terjebak dalam status MENCIPTAKAN, verifikasi bahwa bucket S3 yang Anda petakan berbagi file Anda ada. Untuk informasi tentang cara melakukannya, lihatBerbagi file Anda terjebak dalam status MENCIPTAKAN, sebelumnya.

  2. Jika bucket S3 ada, kemudian verifikasi bahwaAWS Security Token Servicediaktifkan di wilayah tempat Anda membuat berbagi file. Jika token keamanan tidak diaktifkan, Anda harus mengaktifkannya. Untuk informasi tentang cara mengaktifkan tokenAWS Security Token Service, lihatMengaktifkan dan menonaktifkanAWSSTSAWSWilayahdiPanduan Pengguna IAM.

Berbagi file SMB tidak mengizinkan beberapa metode akses yang berbeda

Berbagi file SMB memiliki batasan sebagai berikut:

  1. Ketika klien yang sama mencoba untuk me-mount kedua Active Directory dan Tamu akses file SMB berbagi pesan galat berikut ditampilkan:Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.

  2. Pengguna Windows tidak dapat tetap terhubung ke dua berbagi file SMB Akses Tamu, dan mungkin terputus saat koneksi Akses Tamu baru dibuat.

  3. Klien Windows tidak dapat me-mount akses tamu dan berbagi file SMB Active Directory yang diekspor oleh gateway yang sama.

Beberapa berbagi file tidak dapat menulis ke bucket S3 yang dipetakan

Kami tidak menyarankan mengkonfigurasi bucket S3 Anda untuk memungkinkan beberapa berbagi file untuk menulis ke satu bucket S3. Pendekatan ini dapat menyebabkan hasil yang tidak dapat diprediksi.

Sebagai gantinya, kami sarankan Anda hanya mengizinkan satu berbagi file untuk menulis ke setiap bucket S3. Anda membuat kebijakan bucket untuk hanya mengizinkan peran yang terkait dengan berbagi file Anda untuk menulis ke bucket. Untuk informasi selengkapnya, lihat Praktik terbaik berbagi file.

Tidak dapat mengunggah file ke bucket S3

Jika Anda tidak dapat mengunggah file ke bucket S3, lakukan hal berikut:

  1. Pastikan Anda telah memberikan akses yang diperlukan untuk Amazon S3 File Gateway untuk mengunggah file ke bucket S3 Anda. Untuk informasi selengkapnya, lihat Memberikan akses ke bucket Amazon S3.

  2. Pastikan peran yang membuat bucket memiliki izin untuk menulis ke bucket S3. Untuk informasi selengkapnya, lihat Praktik terbaik berbagi file.

  3. Jika gateway file Anda menggunakan SSE-KMS untuk enkripsi, pastikan peran IAM yang terkait dengan berbagi file termasukkms:Encrypt,kms:Decrypt,KMS: enkripsi kembali,kms:GenerateDataKey, dankms:DescribeKeyizin. Untuk informasi selengkapnya, lihatMenggunakan Kebijakan Berbasis Identitas (Kebijakan IAM) untuk Storage Gateway.

Tidak dapat mengubah enkripsi default untuk menggunakan SSE-KMS untuk mengenkripsi objek yang disimpan dalam bucket S3 saya

Jika Anda mengubah enkripsi default dan membuat SSE-KMS (enkripsi sisi server denganAWS KMS—managed keys) default untuk bucket S3 Anda, objek yang disimpan Amazon S3 File Gateway di bucket tidak dienkripsi dengan SSE-KMS. Secara default, S3 File Gateway menggunakan enkripsi sisi server yang dikelola dengan Amazon S3 (SSE-S3) saat menulis data ke bucket S3. Mengubah default tidak akan secara otomatis mengubah enkripsi Anda.

Untuk mengubah enkripsi untuk menggunakan SSE-KMS dengan milik Anda sendiriAWS KMSkunci, Anda harus mengaktifkan enkripsi SSE-KMS. Untuk melakukannya, Anda memberikan Amazon Resource Name (ARN) dari kunci KMS saat membuat pembagian berkas. Anda juga dapat memperbarui pengaturan KMS untuk berbagi file Anda dengan menggunakanUpdateNFSFileShareatauUpdateSMBFileShareOperasi API. Pembaruan ini berlaku untuk objek yang disimpan dalam ember S3 setelah pembaruan. Untuk informasi selengkapnya, lihat Enkripsi data menggunakanAWS KMS.

Perubahan yang dilakukan secara langsung dalam bucket S3 dengan versi objek diaktifkan dapat memengaruhi apa yang Anda lihat dalam berbagi file Anda

Jika bucket S3 Anda memiliki objek yang ditulis oleh klien lain, pandangan Anda tentang bucket S3 mungkin tidak diperbarui sebagai hasil dari versi objek bucket S3. Anda harus selalu menyegarkan cache Anda sebelum memeriksa file yang menarik.

Pembuatan versi objekadalah fitur bucket S3 opsional yang membantu melindungi data dengan menyimpan beberapa salinan objek yang sama. Setiap salinan memiliki nilai ID terpisah, misalnyafile1.jpg:ID="xxx"danfile1.jpg: ID="yyy". Jumlah objek bernama identik dan masa pakai mereka dikendalikan oleh kebijakan siklus hidup Amazon S3. Untuk detail lebih lanjut tentang konsep Amazon S3 ini, lihatMenggunakan versioningdanManajemen siklus aktif objekdiPanduan Pengembang Amazon S3.

Ketika Anda menghapus objek berversi, objek tersebut ditandai dengan penanda hapus tetapi dipertahankan. Hanya pemilik bucket S3 yang dapat menghapus objek secara permanen dengan versi diaktifkan.

Di S3 File Gateway Anda, file yang ditampilkan adalah versi terbaru dari objek dalam bucket S3 pada saat objek diambil atau cache disegarkan. S3 File Gateway mengabaikan versi lama atau objek yang ditandai untuk dihapus. Saat membaca file, Anda membaca data dari versi terbaru. Ketika Anda menulis file di berbagi file Anda, S3 File Gateway Anda membuat versi baru dari objek bernama dengan perubahan Anda, dan versi itu menjadi versi terbaru.

S3 File Gateway Anda terus membaca dari versi sebelumnya, dan pembaruan yang Anda buat didasarkan pada versi sebelumnya jika versi baru ditambahkan ke bucket S3 di luar aplikasi Anda. Untuk membaca versi terbaru dari sebuah objek, gunakanRefreshCacheAksi API atau refresh dari konsol seperti yang dijelaskan dalamBenda yang menyegarkan di bucket Amazon S3 Anda.

penting

Kami tidak menyarankan agar objek atau file ditulis ke bucket S3 File Gateway S3 Anda dari luar berbagi file.

Saat menulis ke bucket S3 dengan versi objek diaktifkan, Gateway File Amazon S3 dapat membuat beberapa versi objek S3

Dengan versi objek diaktifkan, Anda mungkin memiliki beberapa versi objek yang dibuat di Amazon S3 pada setiap pembaruan ke file dari klien NFS atau SMB Anda. Berikut adalah skenario yang dapat menghasilkan beberapa versi objek yang dibuat dalam bucket S3 Anda:

  • Ketika file dimodifikasi di Gateway File Amazon S3 oleh klien NFS atau SMB setelah diunggah ke Amazon S3, S3 File Gateway mengunggah data baru atau yang dimodifikasi alih-alih mengunggah seluruh file. Modifikasi file menghasilkan versi baru dari objek Amazon S3 yang sedang dibuat.

  • Ketika file ditulis ke S3 File Gateway oleh klien NFS atau SMB, S3 File Gateway mengunggah data file ke Amazon S3 diikuti oleh metadata, (kepemilikan, cap waktu, dll.). Mengunggah data file membuat objek Amazon S3, dan mengunggah metadata untuk file memperbarui metadata untuk objek Amazon S3. Proses ini menciptakan versi lain dari objek, menghasilkan dua versi objek.

  • Ketika S3 File Gateway mengunggah file yang lebih besar, mungkin perlu mengunggah potongan file yang lebih kecil sebelum klien selesai menulis ke gateway file. Beberapa alasan untuk ini termasuk untuk membebaskan ruang cache atau tingkat tinggi menulis ke file. Hal ini dapat menghasilkan beberapa versi dari sebuah objek dalam bucket S3.

Anda harus memantau bucket S3 Anda untuk menentukan berapa banyak versi objek yang ada sebelum menyiapkan kebijakan siklus hidup untuk memindahkan objek ke kelas penyimpanan yang berbeda. Anda harus mengkonfigurasi kedaluwarsa siklus hidup untuk versi sebelumnya untuk meminimalkan jumlah versi yang Anda miliki untuk objek dalam bucket S3 Anda. Penggunaan replikasi Same-Region (SRR) atau Cross-Region replikasi (CRR) antara ember S3 akan meningkatkan penyimpanan yang digunakan. Untuk informasi selengkapnya tentang replikasi, lihatReplikasi.

penting

Jangan mengkonfigurasi replikasi antara ember S3 sampai Anda memahami berapa banyak penyimpanan yang digunakan ketika versi objek diaktifkan.

Penggunaan bucket S3 berversi dapat sangat meningkatkan jumlah penyimpanan di Amazon S3 karena setiap modifikasi pada file menciptakan versi baru dari objek S3. Secara default, Amazon S3 terus menyimpan semua versi ini kecuali jika Anda secara khusus membuat kebijakan untuk mengganti perilaku ini dan membatasi jumlah versi yang disimpan. Jika Anda melihat penggunaan penyimpanan yang luar biasa besar dengan versi objek diaktifkan, periksa apakah kebijakan penyimpanan Anda telah ditetapkan dengan tepat. Peningkatan jumlahHTTP 503-slow downtanggapan untuk permintaan browser juga bisa menjadi hasil dari masalah dengan versi objek.

Jika Anda mengaktifkan versi objek setelah menginstal S3 File Gateway, semua objek unik dipertahankan (ID=”NULL”) dan Anda dapat melihat semuanya dalam sistem file. Versi baru dari objek diberi ID unik (versi lama dipertahankan). Berdasarkan stempel waktu objek hanya objek versi terbaru dapat dilihat dalam sistem file NFS.

Setelah mengaktifkan versi objek, bucket S3 Anda tidak dapat dikembalikan ke status nonversioned. Namun, Anda dapat menangguhkan versioning. Ketika Anda menangguhkan versi, objek baru diberi ID. Jika objek bernama yang sama ada denganID=”NULL”nilai, versi lama ditimpa. Namun, versi apa pun yang berisi non-NULLID dipertahankan. Timestamps mengidentifikasi objek baru sebagai yang saat ini, dan itu adalah salah satu yang muncul dalam sistem file NFS.

Perubahan pada bucket S3 tidak tercermin dalam Storage Gateway

Storage Gateway memperbarui cache berbagi file secara otomatis saat Anda menulis file ke cache secara lokal menggunakan berbagi file. Namun, Storage Gateway tidak memperbarui cache secara otomatis saat Anda mengunggah file langsung ke Amazon S3. Ketika Anda melakukannya, Anda harus melakukanRefreshCacheoperasi untuk melihat perubahan pada file share. Jika Anda memiliki lebih dari satu file share, maka Anda harus menjalankanRefreshCacheoperasi pada setiap berbagi file.

Anda dapat menyegarkan cache menggunakan konsol Storage Gateway danAWS Command Line Interface(AWS CLI):

  • Untuk me-refresh cache menggunakan konsol Storage Gateway, lihat Menyegarkan objek di bucket Amazon S3 Anda.

  • Untuk me-refresh cache menggunakanAWS CLI:

    1. Jalankan perintahaws storagegateway list-file-shares

    2. Salin Amazon Resource Number (ARN) dari berbagi berkas dengan cache yang ingin Anda segarkan.

    3. Jalankanrefresh-cacheperintah dengan ARN Anda sebagai nilai untuk--file-share-arn:

      aws storagegateway refresh-cache --file-share-arn arn:aws:storagegateway:eu-west-1:12345678910:share/share-FFDEE12

Untuk mengotomatiskanRefreshCacheoperasi, lihatBagaimana cara mengotomatisasi operasi RefreshCache di Storage Gateway?

Izin ACL tidak berfungsi seperti yang diharapkan

Jika izin daftar kontrol akses (ACL) tidak berfungsi seperti yang Anda harapkan dengan berbagi file SMB, Anda dapat melakukan tes.

Untuk melakukan ini, pertama menguji izin pada server file Microsoft Windows atau berbagi file Windows lokal. Kemudian bandingkan perilaku dengan berbagi file gateway Anda.

Kinerja gateway Anda ditolak setelah Anda melakukan operasi rekursif

Dalam beberapa kasus, Anda mungkin melakukan operasi rekursif, seperti mengganti nama direktori atau mengaktifkan warisan untuk ACL, dan memaksanya ke bawah pohon. Jika Anda melakukan ini, S3 File Gateway Anda secara rekursif menerapkan operasi ke semua objek dalam berbagi file.

Misalnya, Anda menerapkan warisan untuk objek yang ada di bucket S3. S3 File Gateway secara rekursif menerapkan warisan ke semua objek dalam bucket. Operasi semacam itu dapat menyebabkan kinerja gateway Anda menurun.