Hai, semuanya, dan selamat datang kembali.
Sekarang, dalam video hari ini, kita akan membahas tentang DNS hibrida.
Sekarang, dalam organisasi yang lebih besar, salah satu pola arsitektur umum yang akan Anda lihat adalah bahwa
mereka didasarkan pada pengaturan hibrida.
Jadi, satu bagian dari infrastruktur mungkin ada di bagian kedua dari infrastruktur mungkin ada di pusat data
on-premise, Azure, dan lain-lain.
Sekarang, ketika Anda memiliki pengaturan hibrida, salah satu hal yang menantang adalah terkait dengan resolusi DNS secara keseluruhan.
Dan ini adalah sesuatu yang akan kita bahas dalam video hari ini.
Sekarang, sebelum kita memahami berbagai hal secara mendetail, mari kita ulas kembali dasar-dasar yang berhubungan dengan
zona hosting pribadi pada tinjauan umum.
Zona yang dihosting pribadi berisi catatan yang menentukan bagaimana Anda ingin merutekan lalu lintas di VPC
Amazon.
Sebagai contoh, katakanlah Anda memiliki zona host pribadi dan ada serangkaian catatan tertentu
dan ada dua EPC.
Sekarang, secara default, VPC ini tidak akan dapat melakukan resolusi berdasarkan catatan ini.
Jadi, yang perlu Anda lakukan adalah mengasosiasikan VPC dengan zona yang di-host pribadi dan hanya setelah
asosiasi ini, sumber daya di VPC akan dapat melanjutkan dan melakukan resolusi.
Sekarang, pada tahap ini, karena VPC nomor dua tidak terkait, EC, dua instans dalam VPC ini
tidak akan dapat menyelesaikan catatan dari zona host pribadi khusus ini.
Sekarang, izinkan saya untuk segera menunjukkannya kepada Anda.
Jadi pada tahap ini saya memiliki zona panggilan demo dot internal yang dihosting pribadi.
Jenis yang Anda lihat adalah pribadi yang sekarang dikaitkan dengan zona ini.
Jika saya mengedit zona dengan cepat, Anda memiliki opsi yang terkait dengan mengaitkan VPC dengan zona ini.
Dan pada tahap ini, Anda melihat hanya ada satu VPC yang terkait.
Anda juga memiliki opsi untuk mengaitkan beberapa set VPC yang terkait dengan zona ini sedemikian rupa sehingga semua
catatan yang menjadi bagian dari zona ini akan dapat diselesaikan oleh sumber daya yang terkait dengan
VPC.
Sekarang, satu bagian yang sangat penting untuk diingat adalah bahwa Route 53 tidak merespons permintaan
yang tidak berasal dari VPC.
Sebagai contoh, katakanlah Anda memiliki zona yang di-host pribadi dan Anda memiliki VPC nomor satu yang
dikaitkan dengan zona ini, dan ada juga VPC nomor dua, dan ada peering di antara kedua VPC ini.
Jadi, dua instance yang mudah di VPC dua akan dapat berkomunikasi dengan EC, dua instance di VPC satu
dan sebaliknya.
Sekarang karena VPC satu memiliki akses ke zona host pribadi, diasumsikan bahwa sumber daya di VPC nomor
dua melalui koneksi peering ini akan dapat juga menyelesaikan catatan yang merupakan bagian dari zona
host pribadi.
Akan tetapi, bukan itu masalahnya.
Jadi, jika dua mudah dari VPC nomor dua mengirimkan kueri untuk catatan khusus ini.
Misalnya, 01. titik demo internal ke alamat VPC nomor satu plus dua.
Hal ini tidak akan dapat diselesaikan.
Jadi, mari kita lanjutkan dan juga segera melihat ini.
Sekarang, mirip dengan arsitektur khusus ini, saya sudah memiliki penyiapan infrastruktur.
Jadi di akun nomor satu, saya memiliki instance easy to instance yang sedang berjalan dan saya memiliki
satu lagi instance easy two yang sedang berjalan di akun nomor dua dan kedua VPC tempat EC dua berjalan,
VPC ini muncul.
Sebagai contoh, jika kita melihat ke dalam koneksi peering, Anda melihat ada peering antara akun
nomor satu dan akun nomor dua VPC.
Dan mirip dengan diagram ini, ada zona host pribadi yang dikaitkan dengan VPC nomor satu.
Izinkan saya juga menunjukkan kepada Anda.
Jadi, jika Anda melihat ke dalam asosiasi, ini terkait dengan salah satu VPC, yang kami sebut sebagai
VPC nomor satu.
Sekarang, dari terminal, saya sudah terhubung ke kedua contoh EC ini.
Jadi, EC dua contoh pertama memiliki IP 1077 nol 172.
Sekarang jika Anda melihat Anda memiliki 1077 nol 172 dan yang kedua memiliki IP satu 7231 dan jika Anda melihat di sini Anda
memiliki satu 7231.
Jadi, sebelum kita melanjutkan, mari kita periksa terlebih dahulu, apakah konektivitasnya sudah berhasil.
Jadi dari akun nomor dua, EC dua, saya akan melanjutkan dan saya akan melakukan ping pada EC dua yang terkait dengan
akun nomor satu.
Dan seperti yang diharapkan, pada tahap ini, konektivitas ping berhasil dilakukan.
Sekarang, pada tahap ini poin kedua sangat penting di mana kita membahas alamat VPC plus dua.
Jadi, inilah alamat yang terkait dengan resolusi keseluruhan.
Jadi secara umum, izinkan saya menunjukkan kepada Anda jika kita akan pergi ke konferensi hasil ETSI.
Anda memiliki nilai tambah untuk dialamatkan.
Jadi, jika CIDR VPC adalah 1070 700 16, maka server nama akan menjadi 1077 0. 2.
Baiklah.
Sekarang jika Anda melakukan pencarian di google. com di alamat ini, 1077 0. 2 lagi, jika Anda tidak menyebutkannya, akan menganggap
ini sebagai default.
Tetapi, untuk menghindari kebingungan, saya menambahkannya di sini.
Anda lihat, resolusinya bekerja dengan sangat baik.
Demikian pula, jika Anda mencoba resolusi yang terkait dengan domain zona hosting pribadi, mari kita coba.
Aku akan mengatakan 01. demo dot internal.
Dan Anda lihat, resolusinya juga bekerja dengan sangat baik.
Sekarang, karena sudah ada konektivitas antara VPC satu dan VPC dua, diasumsikan bahwa instance
di VPC dua, jika instance tersebut juga mengirimkan kueri DNS spesifik ini pada alamat plus dua ini, resolusi
akan berhasil.
Namun demikian, kami baru saja mengetahui bahwa ini adalah sesuatu yang tidak didukung, jadi, mari kita coba.
Jadi, jika saya menjalankan perintah yang sama persis di sini, Anda lihat, kami tidak benar-benar mendapatkan respons apa pun di sini.
Dan pada tahap ini kami mendapati koneksi yang habis masa berlakunya yang menyatakan tidak ada server yang dapat dihubungi.
Jadi, inilah yang dimaksud dengan penunjuk pertama di mana kami mengatakan bahwa Route 53 tidak akan menanggapi
permintaan yang tidak berasal dari VPC.
Sekarang, pada tahap ini kita telah membahas tentang peering VPC.
Namun demikian, ini bisa berupa pengaturan apa pun.
Sebagai contoh, jika kita membahas tentang arsitektur hybrid di mana Anda memiliki satu VPC dan Anda
memiliki on premise dan ada konektivitas baik melalui VPN dan koneksi langsung, bahkan dalam kasus seperti itu,
jika sumber daya di on premise mencoba untuk terhubung ke VPC satu ditambah dua alamat IP untuk resolusi, pengaturan
semacam ini tidak didukung.
Sekarang, karena ada banyak organisasi yang secara aktif menggunakan pengaturan semacam itu, pertanyaannya
adalah, apa solusi yang mungkin untuk membuatnya bekerja?
Dan salah satu solusi yang mungkin di sini adalah memperkenalkan server DNS.
Jadi, jika Anda melihat kemungkinan arsitektur khusus ini, apa yang akan Anda lakukan pertama kali
adalah meng-host server DNS khusus di VPC.
Jadi, ini adalah contoh yang mudah untuk dicontoh.
Kemudian, server lokal mengirimkan kueri ke server DNS khusus.
Jadi dari lokasi, alih-alih mengirim ke alamat IP plus dua, Anda mengirimkannya ke alamat IP server
DNS khusus ini.
Sekarang, server DNS khusus ini akan meneruskan kueri ke resolver Route 53 yang sesuai.
Dan dari sini, apa pun respons yang akan diterima server DNS khusus ini, server ini akan meneruskan respons tersebut
kembali ke on-premise.
Dan ini adalah salah satu arsitektur yang sangat umum yang umumnya akan Anda lihat dalam organisasi.
Ini bekerja dengan cukup baik.
Namun demikian, ada beberapa tantangan pada arsitektur semacam ini.
Yang utama pertama adalah pelanggan harus mengelola server DNS khusus, sehingga semua hal yang berkaitan dengan
ketersediaan tinggi, keamanan, optimasi skalabilitas menjadi tanggung jawab pelanggan.
Sekarang, apa yang terjadi karena suatu alasan bahwa instance EC2 yang terkait dengan server DNS kustom ini turun,
seluruh resolusi DNS akan berhenti bekerja dan ini akan memengaruhi aplikasi secara keseluruhan.
Dan inilah salah satu alasan mengapa ia memperkenalkan root 53 resolver endpoint yang memungkinkan kita untuk
berkomunikasi dengan host atau domain privat dari luar VPC.
Jadi di sini, alih-alih server DNS khusus, kami memperkenalkan titik akhir resolver.
Dan manfaat dari titik akhir resolver ini adalah bahwa ia menangani seluruh infrastruktur di sini.
Jadi, Anda tidak perlu terlalu khawatir tentang ketersediaan tinggi, pengoptimalan keamanan, dll. Biarkan kami yang mengurusnya.
Anda hanya perlu membuat titik akhir resolver dan mengirimkan kueri ke alamat IP yang terkait
dengan titik akhir ini dan seluruh penyiapan DNS Anda selesai untuk Anda.
Dan saat ini sebagian besar organisasi, mereka sekarang bermigrasi dari pendekatan server DNS khusus
yang kita bahas ke pendekatan endpoint resolver ini.
Sekali lagi, rangkaian fitur resolver endpoint memberikan banyak fleksibilitas.
Kami akan membahas hal ini dalam video yang sesuai.
Namun demikian, dari perspektif arsitektural, saya harap Anda mendapatkan gambaran mengenai solusi apa yang terkait apabila
Anda memiliki jenis pengaturan hibrida.
Jadi dengan ini akan menyimpulkan video hari ini.