Whitepaper ini hanya untuk referensi sejarah. Beberapa konten mungkin sudah usang dan beberapa tautan mungkin tidak tersedia.
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Arsitektur untuk keamanan dan kinerja
Apakah Anda memilih untuk menjalankan Oracle Database di Amazon RDS atau Amazon EC2, mengoptimalkan setiap komponen infrastruktur akan meningkatkan keamanan, kinerja, dan keandalan. Pada bagian berikut, praktik terbaik untuk mengoptimalkan konfigurasi jaringan, jenis instans, dan penyimpanan database dalam implementasi Oracle Database pada AWS dibahas.
**Topics**
+ [Konfigurasi jaringan](network-configuration.md)
+ [Jenis EC2 instans Amazon](amazon-ec2-instance-type.md)
+ [Penyimpanan basis data](database-storage.md)
# Konfigurasi jaringan
Dengan Amazon Virtual Private Cloud (Amazon VPC), Anda dapat menyediakan bagian yang terisolasi secara logis dari AWS Cloud yang didedikasikan untuk akun Anda. Anda memiliki kontrol penuh atas lingkungan jaringan virtual Anda, termasuk pemilihan rentang alamat IP Anda sendiri, pembuatan subnet, pengaturan keamanan, dan konfigurasi tabel rute dan gateway jaringan.
*Subnet* adalah berbagai alamat IP di VPC Amazon Anda. Anda dapat meluncurkan sumber daya AWS ke subnet yang Anda pilih. Ggunakan subnet publik untuk sumber daya yang harus terhubung ke internet, dan subnet privat untuk sumber daya yang tidak perlu terhubung ke internet.
Untuk melindungi AWS sumber daya di setiap subnet, Anda dapat menggunakan beberapa lapisan keamanan, termasuk grup keamanan dan daftar kontrol akses jaringan (ACLs).
Tabel berikut menjelaskan perbedaan dasar antara kelompok keamanan dan jaringan ACLs.
| **Grup keamanan** | **Jaringan ACL** |
| --- | --- |
| Beroperasi pada tingkat instance (lapisan pertahanan pertama) | Beroperasi di tingkat subnet (lapisan pertahanan kedua) |
| Mendukung hanya mengizinkan aturan | Mendukung mengizinkan aturan dan menolak aturan |
| Stateful: Lalu lintas pengembalian secara otomatis diizinkan, terlepas dari aturan apa pun | Stateless: Lalu lintas pengembalian harus secara eksplisit diizinkan oleh aturan |
| Mengevaluasi semua aturan sebelum memutuskan apakah akan mengizinkan lalu lintas | Memproses aturan dalam urutan numerik saat memutuskan apakah akan mengizinkan lalu lintas |
| Berlaku untuk sebuah instans hanya jika seseorang menentukan grup keamanan ketika meluncurkan instans, atau mengaitkan grup keamanan dengan instans di lain waktu | Secara otomatis berlaku untuk semua instance di subnet yang terkait dengannya (lapisan pertahanan cadangan, jadi Anda tidak harus bergantung pada seseorang yang menentukan grup keamanan) |
Amazon VPC menyediakan isolasi, keamanan tambahan, dan kemampuan untuk memisahkan EC2 instans Amazon menjadi subnet, dan memungkinkan penggunaan alamat IP pribadi. Semua ini penting dalam implementasi database.
Menerapkan instans Oracle Database di subnet pribadi dan hanya mengizinkan server aplikasi dalam VPC Amazon, atau host bastion dalam VPC Amazon, untuk mengakses instance database.
Buat grup keamanan yang sesuai yang memungkinkan akses hanya ke alamat IP tertentu melalui port yang ditunjuk. Rekomendasi ini berlaku untuk Oracle Database terlepas dari apakah Anda menggunakan Amazon RDS atau Amazon. EC2
![\[Oracle Database dalam subnet pribadi dari VPC Amazon\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/oracle-database-aws-best-practices/images/oracle-db-private-subnet.png)
Oracle Database dalam subnet pribadi dari VPC Amazon
# Jenis EC2 instans Amazon
AWS memiliki sejumlah besar jenis EC2 instans Amazon yang tersedia, sehingga Anda dapat memilih jenis instans yang paling sesuai dengan beban kerja Anda. Namun, tidak semua jenis instance yang tersedia paling cocok untuk menjalankan Oracle Database.
Jika Anda menggunakan Amazon RDS untuk Oracle Database, AWS menyaring beberapa jenis instans berdasarkan praktik terbaik, dan memberi Anda berbagai opsi dalam instans kelas T, kelas-M, dan kelas-R. AWS menyarankan Anda memilih instans Amazon RDS berbasis db.m atau berbasis r untuk beban kerja database perusahaan apa pun. Instans R5 sangat cocok untuk aplikasi intensif memori seperti database kinerja tinggi.
Untuk informasi terbaru tentang instans RDS, lihat [Amazon RDS](https://aws.amazon.com/rds/oracle/pricing/) for Oracle Database Pricing. Pilihan jenis instans Amazon RDS Anda harus didasarkan pada beban kerja database dan lisensi Oracle Database yang tersedia.
Jika menjalankan database yang dikelola sendiri di Amazon EC2, Anda memiliki lebih banyak pilihan yang tersedia untuk jenis EC2 instans Amazon. Ini sering menjadi salah satu alasan pengguna memilih untuk menjalankan Oracle Database di Amazon EC2 daripada menggunakan Amazon RDS.
Jenis instance yang sangat kecil tidak cocok karena Oracle Database intensif sumber daya ketika datang ke penggunaan CPU. Instans dengan jejak memori yang lebih besar membantu meningkatkan kinerja database dengan menyediakan caching yang lebih baik dan area global sistem (SGA) yang lebih besar. AWS merekomendasikan agar Anda memilih instance yang memiliki keseimbangan memori dan CPU yang baik.
Pilih jenis instance yang cocok dengan lisensi Oracle Database yang Anda rencanakan untuk digunakan dan arsitektur yang Anda rencanakan untuk diterapkan. Untuk arsitektur yang paling sesuai dengan kebutuhan bisnis Anda, lihat whitepaper [Advanced Architectures for Oracle](https://d1.awsstatic.com/whitepapers/aws-advanced-architectures-for-oracle-db-on-ec2.pdf) Database di Amazon. EC2
Oracle Database banyak menggunakan penyimpanan disk untuk read/write pengoperasian, jadi AWS sangat disarankan agar Anda hanya menggunakan instans yang dioptimalkan untuk Amazon Elastic Block Store (Amazon EBS). Instans Amazon EBS yang dioptimalkan menghadirkan throughput khusus antara Amazon EC2 dan Amazon EBS. Bandwidth dan throughput ke subsistem penyimpanan sangat penting untuk kinerja database yang baik. Pilih instance dengan kinerja jaringan yang lebih tinggi untuk kinerja database yang lebih baik.
Keluarga contoh berikut paling cocok untuk menjalankan Oracle Database di Amazon EC2.
| **Keluarga contoh** | **Fitur** |
| --- | --- |
| Keluarga M | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
| Keluarga X | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
| R keluarga | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
| Saya keluarga | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
| Keluarga Z1d | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
# Penyimpanan basis data
Sebagian besar pengguna biasanya menggunakan Amazon EBS untuk penyimpanan database. Untuk beberapa arsitektur berkinerja sangat tinggi, Anda dapat menggunakan penyimpanan instans SSDs, tetapi mereka harus ditambah dengan penyimpanan Amazon EBS untuk persistensi yang andal.
Untuk kinerja IOPS dan database yang tinggi dan konsisten, AWS sangat merekomendasikan penggunaan volume Tujuan Umum (GP2) atau volume IOPS Terprovisi (PIOPS). GP2 dan volume PIOPS tersedia untuk Amazon EC2 dan Amazon RDS. Lihat [penyimpanan instans Amazon RDS DB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) untuk mengetahui batasan terbaru IOPS per volume untuk keduanya GP2 dan jenis volume PIOPS. GP2 volume memberikan keseimbangan harga dan kinerja yang sangat baik untuk sebagian besar kebutuhan database. Ketika database Anda membutuhkan IOPS yang lebih tinggi daripada yang GP2 dapat disediakan, volume PIOPS adalah pilihan yang tepat.
Untuk volume PIOPS, Anda menentukan tingkat IOPS saat membuat volume, dan Amazon EBS memberikan dalam 10% dari kinerja IOPS yang Disediakan 99,9% dari waktu selama tahun tertentu. Rasio IOPS yang disediakan dengan ukuran volume yang diminta bisa maksimal 30. Misalnya, untuk mendapatkan 3.000 IOPS ukuran volume Anda harus setidaknya 100 GB.
Mirip dengan volume PIOPS, GP2 volume juga berbasis SSD, tetapi IOPS yang Anda dapatkan dari GP2 volume dapat bervariasi dari IOPS dasar hingga 3.000 IOPS per volume yang dapat meledak maksimum. Ini bekerja sangat baik untuk sebagian besar beban kerja database karena kinerja IOPS yang dibutuhkan dari database bervariasi berkali-kali selama periode waktu berdasarkan ukuran beban dan jumlah kueri yang dijalankan.
Kinerja volume Tujuan Umum (SSD) diatur oleh ukuran volume, yang menentukan tingkat kinerja dasar volume dan seberapa cepat ia mengakumulasi I/O kredit. Volume yang lebih besar memiliki tingkat kinerja dasar yang lebih tinggi dan mengakumulasi I/O kredit lebih cepat.
I/O kredit mewakili bandwidth yang tersedia yang dapat digunakan volume General Purpose (SSD) Anda untuk meledak dalam jumlah besar I/O ketika lebih dari kinerja dasar yang dibutuhkan. Semakin banyak kredit yang dimiliki volume Anda untuk I/O, semakin banyak waktu yang dapat meledak melampaui tingkat kinerja dasarnya dan semakin baik kinerjanya ketika lebih banyak kinerja diperlukan.
Throughput Optimized HDD volume (st1) menawarkan volume HDD berbiaya rendah yang dirancang untuk beban kerja intensif yang membutuhkan lebih sedikit IOPS tetapi throughput tinggi. Database Oracle yang digunakan untuk gudang data dan keperluan analisis data dapat memanfaatkan volume st1.
Setiap pemrosesan log atau area pementasan data seperti tabel eksternal Oracle atau penyimpanan BLOB eksternal yang memerlukan throughput tinggi dapat memanfaatkan volume st1. Volume throughput yang dioptimalkan (st1) dapat menangani maks 500 IOPS per volume.
Volume HDD dingin (sc1) cocok untuk menangani sistem lama, yang disimpan untuk tujuan referensi atau arsip sesekali. Sistem ini diakses lebih jarang dan beberapa pemindaian dilakukan per hari pada volume.
Pendekatan yang baik adalah memperkirakan jumlah IOPS yang secara konsisten diperlukan untuk database Anda, dan mengalokasikan GP2 penyimpanan yang cukup untuk mendapatkan IOPS sebanyak itu. IOPS tambahan apa pun yang diperlukan untuk lonjakan berkala harus dicakup oleh kinerja burst berdasarkan kredit yang tersedia.
Untuk informasi tentang metode estimasi yang dapat Anda gunakan untuk menentukan kebutuhan IOPS dari Oracle Database Anda, lihat whitepaper [Menentukan Kebutuhan IOPS untuk Oracle Database](https://docs.aws.amazon.com/whitepapers/latest/determining-iops-needs-oracle-db-on-aws/determining-iops-needs-oracle-db-on-aws.html) on AWS.
Durasi runtutan volume tergantung pada ukuran volume, IOPS runtut yang diperlukan, dan saldo kredit saat runtutan dimulai. Jika Anda memperhatikan bahwa kinerja volume Anda sering terbatas pada tingkat dasar (karena saldo I/O kredit kosong), Anda harus mempertimbangkan untuk menggunakan volume General Purpose (SSD) yang lebih besar (dengan tingkat kinerja dasar yang lebih tinggi) atau beralih ke volume IOPS (SSD) yang Disediakan untuk beban kerja yang membutuhkan kinerja IOPS berkelanjutan lebih dari 10.000 IOPS. Untuk detail tambahan tentang GP2 volume, lihat [jenis volume Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html).
Untuk Amazon RDS, penyimpanan General Purpose (SSD) memberikan baseline yang konsisten sebesar 3 IOPS per GB yang disediakan dan menyediakan kemampuan untuk meledak hingga 3.000 IOPS. Jika Anda sudah menggunakan penyimpanan magnetik untuk Amazon RDS, Anda dapat mengonversi ke penyimpanan Tujuan Umum (SSD), tetapi Anda akan mengalami dampak ketersediaan yang singkat saat melakukannya. Menggunakan IOPS Terketentuan, Anda dapat menyediakan hingga batas penyimpanan maksimum saat ini dan IOPS maksimum per instance database.
IOPS realisasi Anda yang sebenarnya dapat bervariasi dari jumlah yang Anda berikan berdasarkan beban kerja database, jenis instans, dan mesin database Anda. Untuk informasi selengkapnya, lihat [Faktor-faktor yang Mempengaruhi Tarif IOPS Terealisasi di *Panduan Pengguna Amazon RDS*](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html).
Untuk Oracle Database di Amazon EC2, gabungkan beberapa volume untuk IOPS lebih banyak dan kapasitas yang lebih besar. Anda dapat menggunakan beberapa volume Amazon EBS satu per satu untuk file data yang berbeda, tetapi menyatukannya memungkinkan keseimbangan dan skalabilitas yang lebih baik.
Oracle Automatic Storage Management (ASM) dapat digunakan untuk striping. Simpan file data, file log, dan binari pada volume Amazon EBS yang terpisah, dan ambil snapshot volume file log secara teratur. Memilih jenis instans dengan penyimpanan SSD lokal memungkinkan Anda untuk meningkatkan kinerja database dengan menggunakan Smart Flash Cache (jika sistem operasinya adalah Oracle Linux) dan dengan menggunakan penyimpanan lokal untuk file sementara dan ruang tabel.
Untuk Oracle Database on VMware Cloud on AWS, vSAN menyediakan penyimpanan tervirtualisasi yang diperlukan di seluruh host bare metal. Kemampuan penyimpanan tervirtualisasi vSAN dapat digunakan di Oracle RAC untuk penyimpanan bersama berkinerja tinggi.
File VMDK (disk mesin virtual) yang dibuat untuk Oracle RAC harus disediakan dengan ketebalan nol yang bersemangat dan diaktifkan bendera multi-penulis. VMware telah menerbitkan [studi kinerja terperinci](https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/solutions/oracle/vmw-oracle-performance-on-the-vmware-cloud-on-aws.pdf) untuk database Oracle di VMware Cloud di AWS.