Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Arsitektur Amazon RDS Custom
Arsitektur Amazon RDS Custom didasarkan pada Amazon RDS, dengan perbedaan penting. Diagram berikut menunjukkan komponen utama arsitektur RDS Custom.
VPC
Seperti di Amazon RDS, instans DB RDS Custom Anda berada di cloud privat virtual (VPC).
Instans DB RDS Custom Anda terdiri dari komponen utama berikut:
-
Instans Amazon EC2
-
Titik akhir instans
-
Sistem operasi diinstal pada instans Amazon EC2
-
Penyimpanan Amazon EBS yang berisi sistem file tambahan
Otomatisasi dan pemantauan RDS Custom
RDS Custom memiliki perangkat lunak otomatisasi yang berjalan di luar instans DB. Perangkat lunak ini berkomunikasi dengan agen pada instans DB dan dengan komponen lain dalam lingkungan RDS Custom secara keseluruhan.
Fitur pemantauan dan pemulihan RDS Custom menawarkan fungsionalitas yang mirip dengan Amazon RDS. Secara default, RDS Custom dalam mode otomatisasi penuh. Perangkat lunak otomatisasi memiliki tanggung jawab utama sebagai berikut:
-
Mengumpulkan metrik dan mengirimkan pemberitahuan
-
Melakukan pemulihan instans otomatis
Tanggung jawab penting otomatisasi RDS Custom adalah merespons masalah instans Amazon EC2 Anda. Karena berbagai alasan, host mungkin terganggu atau tidak dapat dijangkau. RDS Custom menyelesaikan masalah ini dengan boot ulang atau penggantian instans Amazon EC2.
Penggantian host Amazon RDS Custom
Jika host Amazon EC2 mengalami gangguan, RDS Custom mencoba untuk boot ulang. Jika upaya ini gagal, RDS Custom menggunakan fitur hentikan dan mulai yang sama yang disertakan dalam Amazon EC2. Satu-satunya perubahan yang terlihat oleh pelanggan ketika host diganti adalah alamat IP publik baru.
Menghentikan dan memulai host
RDS Custom mengambil langkah-langkah berikut secara otomatis, tanpa memerlukan intervensi pengguna:
-
Menghentikan host Amazon EC2.
Instans EC2 melakukan pematian normal dan berhenti berjalan. Semua volume Amazon EBS tetap terlampir pada instans dan datanya tetap ada. Setiap data yang disimpan dalam volume penyimpanan instans (tidak didukung pada RDS Custom) atau RAM komputer host hilang.
Untuk informasi selengkapnya, lihat Menghentikan dan memulai instans Anda di Panduan Pengguna Amazon EC2.
-
Memulai host Amazon EC2.
Instans EC2 bermigrasi ke perangkat keras host baru yang mendasarinya. Dalam beberapa kasus, instans DB RDS Custom tetap berada di host asli.
Efek penggantian host
Di RDS Custom, Anda memiliki kontrol penuh atas volume perangkat root dan volume penyimpanan Amazon EBS. Volume root dapat berisi data dan konfigurasi penting yang tidak ingin Anda hilangkan.
RDS Custom for Oracle mempertahankan semua basis data dan data pelanggan setelah operasi, termasuk data volume root. Tidak perlu ada intervensi pengguna. Pada RDS Custom for SQL Server, data basis data dipertahankan, tetapi semua data pada drive C:, termasuk sistem operasi dan data pelanggan, hilang.
Setelah proses penggantian, host Amazon EC2 memiliki alamat IP publik baru. Host mempertahankan hal berikut:
-
ID Instans
-
Alamat IP privat
-
Alamat IP elastis
-
Metadata instans
-
Data volume penyimpanan data
-
Data volume root (pada RDS Custom for Oracle)
Praktik terbaik untuk host Amazon EC2
Fitur penggantian host Amazon EC2 mencakup sebagian besar skenario gangguan Amazon EC2. Sebaiknya Anda untuk mematuhi praktik terbaik berikut:
-
Sebelum mengubah konfigurasi atau sistem operasi, cadangkan data Anda. Jika volume root atau sistem operasi rusak, penggantian host tidak dapat memperbaikinya. Satu-satunya pilihan Anda adalah memulihkan dari snapshot atau point-in-time pemulihan DB.
-
Jangan menghentikan atau mengakhiri host Amazon EC2 fisik secara manual. Kedua tindakan tersebut mengakibatkan instans ditempatkan di luar perimeter dukungan RDS Custom.
-
(RDS Custom for SQL Server) Jika Anda melampirkan volume tambahan ke host Amazon EC2, konfigurasikan untuk dipasang kembali saat memulai ulang. Jika host mengalami gangguan, RDS Custom mungkin menghentikan dan memulai host secara otomatis.
Perimeter dukungan RDS Custom
RDS Custom menyediakan kemampuan pemantauan tambahan yang disebut perimeter dukungan. Pemantauan tambahan ini memastikan bahwa instans RDS Custom DB Anda menggunakan AWS infrastruktur, sistem operasi, dan database yang didukung.
Perimeter dukungan memeriksa apakah instans DB Anda sesuai dengan persyaratan yang tercantum dalam Memperbaiki konfigurasi yang tidak didukung di RDS Custom for Oracle dan Memperbaiki konfigurasi yang tidak didukung di RDS Custom for SQL Server. Jika salah satu persyaratan ini tidak terpenuhi, RDS Custom menganggap instans DB Anda berada di luar perimeter dukungan.
Topik
Konfigurasi yang tidak didukung di RDS Custom
Saat instans DB Anda berada di luar perimeter dukungan, RDS Custom mengubah status instans DB menjadi unsupported-configuration dan mengirimkan pemberitahuan peristiwa. Setelah Anda memperbaiki masalah konfigurasi, RDS Custom mengubah status instans DB kembali ke available.
Saat instans DB Anda dalam status unsupported-configuration, pernyataan berikut benar:
-
Basis data Anda dapat dijangkau. Terdapat pengecualian ketika instans DB berstatus
unsupported-configurationkarena basis data mati secara tidak terduga. -
Anda tidak dapat memodifikasi instans DB Anda.
-
Anda tidak dapat mengambil snapshot DB.
-
Pencadangan otomatis tidak dibuat.
-
Khusus untuk instans DB RDS Custom for SQL Server, RDS Custom tidak mengganti instans Amazon EC2 yang mendasarinya jika mengalami gangguan. Untuk informasi selengkapnya tentang penggantian host, lihat Penggantian host Amazon RDS Custom.
-
Anda dapat menghapus instans DB, tetapi sebagian besar operasi API RDS Custom lainnya tidak tersedia.
-
RDS Custom terus mendukung point-in-time pemulihan (PITR) dengan mengarsipkan file log redo dan mengunggahnya ke Amazon S3. PITR dalam status
unsupported-configurationberbeda dalam hal berikut:-
PITR mungkin memerlukan waktu lama untuk memulihkan sepenuhnya ke instans DB RDS Custom baru. Situasi ini terjadi karena Anda tidak dapat mengambil snapshot otomatis atau manual saat instans dalam status
unsupported-configuration. -
PITR harus memutar ulang lebih banyak log pengulangan mulai dari snapshot terbaru yang diambil sebelum instans memasuki status
unsupported-configuration. -
Dalam beberapa kasus, instans DB berada dalam status
unsupported-configurationkarena Anda membuat perubahan yang mencegah pengunggahan file log pengulangan yang diarsipkan. Contohnya termasuk menghentikan instans EC2, menghentikan agen RDS Custom, dan melepaskan volume EBS. Dalam kasus seperti itu, PITR tidak dapat memulihkan instans DB ke waktu pemulihan terbaru.
-
Memecahkan masalah konfigurasi yang tidak didukung
RDS Custom menyediakan panduan pemecahan masalah untuk status unsupported-configuration. Meskipun beberapa panduan berlaku untuk RDS Custom for Oracle dan RDS Custom for SQL Server, panduan lain bergantung pada mesin DB Anda. Untuk informasi pemecahan masalah khusus mesin, lihat topik berikut:
Amazon S3
Jika menggunakan RDS Custom for Oracle, Anda mengunggah media instalasi ke bucket Amazon S3 buatan pengguna. RDS Custom for Oracle menggunakan media di bucket ini untuk membuat versi mesin kustom (CEV). CEV adalah snapshot volume biner dari versi basis data dan Amazon Machine Image (AMI). Dari CEV, Anda dapat membuat instans DB RDS Custom. Untuk informasi selengkapnya, lihat Menggunakan versi mesin kustom untuk Amazon RDS Custom for Oracle.
Untuk RDS Custom for Oracle dan RDS Custom for SQL Server, RDS Custom otomatis membuat bucket Amazon S3 yang diawali dengan string do-not-delete-rds-custom-. RDS Custom menggunakan bucket S3 do-not-delete-rds-custom- untuk menyimpan jenis file berikut:
-
AWS CloudTrail log untuk jejak yang dibuat oleh RDS Custom
-
Artefak perimeter dukungan (lihat Perimeter dukungan RDS Custom)
-
File log pengulangan basis data (khusus RDS Custom for Oracle)
-
Log transaksi (khusus RDS Custom for SQL Server)
-
Artefak versi mesin kustom (khusus RDS Custom for Oracle)
RDS Custom membuat bucket S3 do-not-delete-rds-custom- saat Anda membuat salah satu sumber daya berikut:
-
CEV pertama untuk RDS Custom for Oracle
-
Instans DB pertama untuk RDS Custom for SQL Server
RDS Custom membuat satu bucket untuk setiap kombinasi berikut:
-
Akun AWS ID
-
Jenis mesin (baik RDS Custom for Oracle atau RDS Custom for SQL Server)
-
Wilayah AWS
Misalnya, jika Anda membuat RDS Custom untuk CEV Oracle dalam satu Wilayah AWS, ada satu bucket. do-not-delete-rds-custom- Jika Anda membuat beberapa instans RDS Custom untuk SQL Server, dan mereka berada di tempat yang berbeda Wilayah AWS, satu do-not-delete-rds-custom- bucket ada di masing-masing. Wilayah AWS Jika Anda membuat satu contoh RDS Custom untuk Oracle dan dua instance RDS Custom untuk SQL Server dalam satu Wilayah AWS, dua bucket ada. do-not-delete-rds-custom-
AWS CloudTrail
RDS Custom secara otomatis membuat AWS CloudTrail jejak yang namanya dimulai dengando-not-delete-rds-custom-. Perimeter dukungan Kustom RDS bergantung pada peristiwa dari CloudTrail untuk menentukan apakah tindakan Anda memengaruhi otomatisasi Kustom RDS. Untuk informasi selengkapnya, lihat Memecahkan masalah konfigurasi yang tidak didukung.
RDS Custom membuat jejak saat Anda membuat instans DB pertama. RDS Custom membuat satu jejak untuk setiap kombinasi berikut:
-
Akun AWS ID
-
Jenis mesin (baik RDS Custom for Oracle atau RDS Custom for SQL Server)
-
Wilayah AWS
Saat Anda menghapus instans RDS Custom DB, instance ini tidak dihapus secara otomatis. CloudTrail Dalam hal ini, Anda Akun AWS terus ditagih untuk yang tidak CloudTrail dihapus. RDS Custom tidak bertanggung jawab atas penghapusan sumber daya ini. Untuk mempelajari cara menghapus secara CloudTrail manual, lihat Menghapus jejak di Panduan AWS CloudTrail Pengguna.
