Pemecahan masalah: masalah berbagi file - AWS Storage Gateway

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

Pemecahan masalah: masalah berbagi file

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

Berbagi file Anda macet dalam status CREATING

Saat berbagi file Anda sedang dibuat, statusnya adalah CREATING. Transisi status ke status AVAILABLE setelah berbagi file dibuat. Jika berbagi file Anda macet dalam status CREATING, lakukan hal berikut:

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

  2. Pastikan bucket S3 tempat Anda memetakan file share Anda ada. Jika ember tidak ada, buatlah. Setelah Anda membuat bucket, status berbagi file akan beralih ke AVAILABLE. Untuk informasi tentang cara membuat bucket S3, lihat Membuat bucket di Panduan Pengguna Layanan Penyimpanan Sederhana Amazon.

  3. Pastikan nama bucket Anda sesuai dengan aturan penamaan bucket di Amazon S3. Untuk informasi selengkapnya, lihat Aturan untuk penamaan bucket di Panduan Pengguna Layanan Penyimpanan Sederhana Amazon.

    catatan

    S3 File Gateway tidak mendukung bucket Amazon S3 dengan period . () dalam nama bucket.

  4. Pastikan peran IAM yang Anda gunakan untuk mengakses bucket S3 memiliki izin yang benar dan verifikasi 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 macet dalam status CREATING, verifikasi bahwa bucket S3 tempat Anda memetakan file share sudah ada. Untuk informasi tentang cara melakukannya, lihatBerbagi file Anda macet dalam status CREATING, sebelumnya.

  2. Jika bucket S3 ada, maka verifikasi yang AWS Security Token Service diaktifkan di wilayah tempat Anda membuat file share. Jika token keamanan tidak aktif, Anda harus mengaktifkannya. Untuk informasi tentang cara mengaktifkan token menggunakan AWS Security Token Service, lihat Mengaktifkan dan menonaktifkan AWS STS di AWS Wilayah dalam Panduan 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 memasang file SMB Active Directory dan akses Tamu, pesan kesalahan berikut akan 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 memasang akses tamu dan berbagi file SMB Direktori Aktif yang diekspor oleh gateway yang sama.

Beberapa berbagi file tidak dapat menulis ke bucket S3 yang dipetakan

Kami tidak menyarankan mengonfigurasi bucket S3 Anda untuk memungkinkan beberapa pembagian file ditulis ke satu bucket S3. Pendekatan ini dapat menyebabkan hasil yang tidak terduga.

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

Pemberitahuan untuk grup log yang dihapus saat menggunakan log audit

Jika grup log tidak ada, pengguna dapat memilih tautan grup log di bawah pesan tersebut untuk membuat grup log baru atau menggunakan grup log yang ada untuk digunakan sebagai target log audit

Tidak dapat mengunggah file ke bucket S3 Anda

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 untuk Gateway File.

  3. Jika File Gateway Anda menggunakan SSE-KMS atau DSSE-KMS untuk enkripsi, pastikan peran IAM yang terkait dengan berbagi file mencakup izin KMS:Encrypt, KMS:Decrypt, kms: *, kms:, dan kms:. ReEncrypt GenerateDataKey DescribeKey Untuk informasi selengkapnya, lihat Menggunakan Kebijakan Berbasis Identitas (Kebijakan IAM) untuk Storage Gateway.

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

Jika Anda mengubah enkripsi default dan menjadikan SSE-KMS (enkripsi sisi server dengan kunci yang AWS KMS dikelola) sebagai default untuk bucket S3, objek yang disimpan oleh Amazon S3 File Gateway dalam bucket tidak dienkripsi dengan SSE-KMS. Secara default, Gateway File S3 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 AWS KMS kunci Anda sendiri, Anda harus mengaktifkan enkripsi SSE-KMS. Untuk melakukannya, Anda memberikan Nama Sumber Daya Amazon (ARN) dari kunci KMS saat Anda membuat berbagi file. Anda juga dapat memperbarui pengaturan KMS untuk berbagi file Anda dengan menggunakan operasi UpdateNFSFileShare atau UpdateSMBFileShare API. Pembaruan ini berlaku untuk objek yang disimpan dalam bucket S3 setelah pembaruan. Untuk informasi selengkapnya, lihat Enkripsi data menggunakan AWS KMS.

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

Jika bucket S3 Anda memiliki objek yang ditulis oleh klien lain, tampilan bucket S3 Anda mungkin bukan up-to-date karena pembuatan versi objek bucket S3. Anda harus selalu menyegarkan cache Anda sebelum memeriksa file yang menarik.

Pembuatan versi objek adalah fitur bucket S3 opsional yang membantu melindungi data dengan menyimpan banyak salinan objek dengan nama yang sama. Setiap salinan memiliki nilai ID terpisah, misalnyafile1.jpg: ID="xxx" danfile1.jpg:ID="yyy". Jumlah objek yang diberi nama identik dan masa pakainya dikendalikan oleh kebijakan siklus hidup Amazon S3. Untuk detail selengkapnya tentang konsep Amazon S3 ini, lihat Menggunakan pembuatan versi dan manajemen siklus hidup Objek di Panduan Pengembang Amazon S3.

Saat 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 di-refresh. S3 File Gateways mengabaikan versi lama atau objek apa pun yang ditandai untuk dihapus. Saat membaca file, Anda membaca data dari versi terbaru. Saat Anda menulis file di berbagi file, Gateway File S3 Anda membuat versi baru dari objek bernama dengan perubahan Anda, dan versi itu menjadi versi terbaru.

Gateway File S3 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 objek, gunakan tindakan RefreshCacheAPI atau refresh dari konsol seperti yang dijelaskan dalamMenyegarkan cache objek bucket Amazon S3.

penting

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

Saat menulis ke bucket S3 dengan versi diaktifkan, Amazon S3 File Gateway dapat membuat beberapa versi objek Amazon 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 di bucket S3 Anda:

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

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

  • Saat S3 File Gateway mengunggah file yang lebih besar, mungkin perlu mengunggah potongan file yang lebih kecil sebelum klien selesai menulis ke File Gateway. Beberapa alasan untuk ini termasuk untuk membebaskan ruang cache atau tingkat penulisan yang tinggi ke file. Ini dapat menghasilkan beberapa versi objek di bucket S3.

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

penting

Jangan mengonfigurasi replikasi antara bucket S3 sampai Anda memahami berapa banyak penyimpanan yang digunakan saat pembuatan versi objek dihidupkan.

Penggunaan bucket S3 berversi dapat sangat meningkatkan jumlah penyimpanan di Amazon S3 karena setiap modifikasi pada file membuat versi baru dari objek S3. Secara default, Amazon S3 terus menyimpan semua versi ini kecuali 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 ditetapkan dengan tepat. Peningkatan jumlah HTTP 503-slow down tanggapan untuk permintaan browser juga dapat menjadi hasil dari masalah dengan versi objek.

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

Setelah Anda mengaktifkan versi objek, bucket S3 Anda tidak dapat dikembalikan ke status nonversioned. Namun, Anda dapat menangguhkan pembuatan versi. Saat Anda menangguhkan pembuatan versi, objek baru diberi ID. Jika objek bernama yang sama ada dengan ID=”NULL” nilai, versi yang lebih lama akan ditimpa. Namun, versi apa pun yang berisi NULL non-ID dipertahankan. Stempel waktu mengidentifikasi objek baru sebagai yang sekarang, dan itulah yang muncul di sistem file NFS.

Perubahan pada bucket S3 tidak tercermin di Storage Gateway

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

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

  • Untuk menyegarkan cache menggunakan konsol Storage Gateway, lihat Menyegarkan objek di bucket Amazon S3.

  • Untuk menyegarkan cache menggunakan AWS CLI:

    1. Jalankan perintah aws storagegateway list-file-shares

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

    3. Jalankan refresh-cache perintah 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 mengotomatiskan RefreshCache operasi, lihat Bagaimana cara mengotomatiskan RefreshCache operasi 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 pengujian.

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

Performa gateway Anda menurun setelah Anda melakukan operasi rekursif

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

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