GCP-NETWORK

Sejauh ini, Anda telah mempelajari project, jaringan, subnetwork, dan alamat IP. Mari gunakan
hal yang telah dipetik untuk memahami cara GCP merutekan traffic. Secara default, setiap jaringan
memiliki rute yang mengizinkan instance di jaringan mengirimkan traffic secara langsung ke satu sama
lain, bahkan lintas subnet. Selain itu, setiap jaringan memiliki rute default yang mengarahkan paket ke
tujuan yang berada di luar jaringan. Meski mencakup sebagian besar kebutuhan perutean secara umum,
Anda juga dapat membuat rute khusus yang mengganti rute ini. Hanya karena paket memiliki rute ke
tujuan, tidak berarti paket tersebut bisa sampai ke tujuan. Aturan firewall juga harus mengizinkan paket.
Jaringan default memiliki aturan firewall yang telah dikonfigurasi yang memungkinkan semua instance di
jaringan berbicara satu sama lain. Jaringan yang dibuat secara manual tidak memiliki aturan tersebut.
Anda harus membuat aturan tersebut seperti yang akan Anda pelajari di lab pertama. Rute
mencocokkan paket dengan alamat IP tujuan. Namun, traffic tidak akan mengalir tanpa aturan firewall
yang cocok. Rute dibuat saat jaringan dibuat, memungkinkan pengiriman traffic dari mana saja. Selain
itu, rute dibuat saat subnet dibuat. Hal ini memungkinkan VM di subnet yang sama berkomunikasi
secara internal. Slide ini menampilkan tabel perutean yang disederhanakan, tapi mari kita lihat slide ini
lebih dekat. Setiap rute di kumpulan rute dapat berlaku untuk satu atau beberapa instance. Rute berlaku
untuk instance, jika jaringan dan tumpukan instance cocok. Jika jaringan cocok dan tag instance tidak
ditentukan, rute akan berlaku untuk semua instance di jaringan tersebut. Kemudian, Compute Engine
menggunakan kumpulan rute untuk membuat tabel perutean individual hanya baca untuk setiap
instance. Diagram ini menunjukkan router virtual yang sangat skalabel di inti setiap jaringan. Setiap
instance mesin virtual di jaringan langsung terhubung dengan router ini, dan semua paket yang
meninggalkan instance mesin virtual pertama ditangani di lapisan ini sebelum diteruskan ke
pemberhentian berikutnya. Router jaringan virtual memilih pemberhentian berikutnya untuk paket
dengan memeriksa tabel penulisan untuk instance tersebut. Di diagram ini, kotak hijau adalah instance
mesin virtual, router adalah yang berwarna kuning di tengah, dan tabel perutean individual ditunjukkan
dengan 10 kotak. Aturan firewall GCP melindungi instance mesin virtual dari sambungan yang tidak
disetujui, sambungan masuk dan keluar yang masing-masing disebut ingress dan egress. Pada dasarnya,
setiap jaringan VPC berfungsi sebagai firewall terdistribusi. Meski aturan firewall berlaku untuk jaringan
secara keseluruhan, sambungan diizinkan atau ditolak pada tingkat instance. Anda dapat menganggap
keberadaan firewall tidak hanya di antara instance dan jaringan lainnya, tetapi juga di instance individual
dalam jaringan yang sama. Selain itu, jika untuk alasan tertentu semua aturan firewall di jaringan
dihapus, akan tetap ada aturan tolak semua ingress tersirat, dan aturan izinkan semua egress tersirat
untuk jaringan. Anda dapat mengekspresikan konfigurasi firewall yang diinginkan sebagai kumpulan
aturan firewall. Secara konseptual, aturan firewall dibuat dari parameter berikut. Arah aturan.
Sambungan masuk dicocokkan hanya dengan aturan ingress, dan sambungan outbound dicocokkan
hanya dengan aturan egress, sumber sambungan untuk paket ingress atau tujuan sambungan untuk
paket egress. Terdapat protokol dan port sambungan, tempat aturan dapat dibatasi penerapannya ke
protokol tertentu saja atau hanya ke kombinasi protokol dan port tertentu. Ada tindakan aturan, yang
mengizinkan atau menolak paket agar sesuai dengan arah, port protokol, dan sumber atau tujuan
aturan, prioritas aturan yang mengatur urutan aturan dievaluasi, berlaku aturan yang pertama cocok,
dan penetapan aturan. Secara default, semua aturan ditetapkan ke semua instance, tetapi Anda dapat
menetapkan aturan tertentu hanya untuk instance tertentu. Mari kita lihat beberapa kasus penggunaan
firewall GCP untuk egress dan ingress. Aturan firewall egress mengontrol sambungan keluar yang
berasal dari dalam jaringan GCP Anda. Aturan izinkan egress mengizinkan sambungan terbuka yang
sesuai dengan protokol, port, dan alamat IP tertentu. Aturan tolak egress mencegah instance memulai
sambungan yang cocok dengan kombinasi port, protokol, dan rentang IP yang tidak diizinkan. Untuk
aturan firewall egress, tujuan tempat aturan berlaku dapat ditentukan dengan rentang CIDR IP.
Khususnya, Anda dapat menggunakan rentang tujuan untuk melindungi dari sambungan yang tidak
diinginkan, yang dibuka oleh instance VM ke tujuan eksternal. Misalnya, seperti yang ditampilkan di kiri,
host eksternal. Rentang tujuan juga dapat digunakan untuk melindungi dari sambungan tak diinginkan,
yang diawali instance VM ke rentang CIDR GCP tertentu. Misalnya, seperti yang ditunjukkan di tengah,
VM dalam subnet tertentu. Aturan firewall ingress melindungi dari sambungan masuk ke instance dari
sumber mana pun. Aturan izinkan ingress mengizinkan protokol, port, dan alamat IP tertentu untuk
tersambung. Firewall mencegah instance agar tidak menerima sambungan port dan protokol yang tidak
diizinkan. Aturan dapat dibatasi untuk hanya memengaruhi sumber tertentu. Rentang CIDR sumber
dapat berfungsi melindungi dari sambungan tak diinginkan yang menuju instance dari jaringan eksternal
atau rentang CIDR IP GCP. Selain itu, teks sumber dapat digunakan untuk melindungi dari sambungan
yang tidak diinginkan yang berasal dari instance VM tertentu yang diberi tag dengan tag yang cocok.
Diagram ini menunjukkan VM yang menerima sambungan dari alamat eksternal, dan VM lain yang
menerima sambungan dari VM dalam jaringan yang sama. Anda dapat mengontrol sambungan ingress
dari instance VM dengan mengatur kondisi sambungan masuk menggunakan rentang CIDR sumber,
protokol, port, dan Tag sumber di instance. Namun, Tag sumber hanya dapat digunakan untuk
sambungan VM ke VM seperti yang ditampilkan di tengah.

-) Disk Options
Sampai titik ini, Anda sudah memilih sistem operasi, namun, sistem operasi itu akan disertakan
sebagai bagian dari jenis disk tertentu. Mari kita lihat opsi disk. Setiap VM sudah memiliki satu root
persistent disk karena Anda memilih satu gambar dasar yang akan dimuat. Gambar ini dapat dibooting
dan Anda dapat melampirkannya ke VM dan melakukan booting dari VM itu. Gambar ini tahan lama dan
tetap ada jika VM dihentikan. Agar booting tetap ada setelah VP dihapus, kotak "Hapus disk booting saat
instance dihapus" harus dikosongkan di properti instance. Seperti yang sudah dibahas, ada berbagai
jenis disk. Mari kita pelajari jenis-jenisnya secara lebih mendetail. Disk pertama yang kita buat disebut
persistent disk. Artinya, disk itu akan dipasang ke VM melalui antarmuka jaringan. Meskipun berupa
persistent disk, disk ini tidak terpasang secara fisik ke VM. Pemisahan disk & komputasi ini menjadikan
disk tetap ada jika VM dihentikan. Namun, persistent disk terikat ke zonanya dan tidak dapat
dipindahkan ke zona lain. Anda juga dapat melakukan snapshot pada disk ini yang merupakan backup
inkremental, yang akan kita bahas nanti. Pemilihan antara disk HDD dan SSD ditentukan oleh biaya dan
performa. Untuk mempelajari lebih lanjut, sebaiknya Anda membuka link dokumentasi di sini karena
performa sering meningkat. Fitur keren lainnya dari persistent disk adalah Anda dapat menyesuaikan
ukuran secara dinamis meski disk berjalan dan terpasang ke VM. Anda juga dapat memasang disk dalam
mode hanya baca ke beberapa VM. Ini memungkinkan Anda berbagi data statis antara beberapa
instance, yang lebih murah dibandingkan dengan mereplikasikan data ke disk unik untuk tiap instance.
SSD lokal berbeda dengan persistent disk, dan SSD lokal terpasang secara fisik ke mesin virtual.
Karenanya, disk ini bersifat efemeral, namun menyediakan ion yang sangat tinggi. Untuk jumlah terbaru,
sebaiknya Anda melihat dokumentasi. Saat ini, Anda dapat memasang maksimal 8 disk SSD lokal yang
masing-masing berukuran 375 GB, dengan total 3 TB. Data di disk ini akan tetap ada setelah reset tetapi
akan hilang jika VP berhenti atau dihentikan karena disk ini tidak dapat dipasang ulang ke VM lainnya.
Anda juga dapat menggunakan disk RAM. Anda cukup menggunakan TMPFS jika ingin menyimpan data
di memori. Ini akan menghasilkan jenis performa tercepat yang tersedia jika Anda memerlukan struktur
data berukuran kecil. Sebaiknya gunakan mesin virtual dengan memori besar jika Anda ingin
memanfaatkan fitur semacam itu beserta persistent disk untuk melakukan backup pada data disk RAM.
Singkatnya, Anda memiliki banyak opsi disk yang berbeda. Persistent disk dapat dibooting dan di-
snapshot, namun SSD lokal dan disk RAM bersifat efemeral.

Sebaiknya pilih disk HDD persistent jika Anda hanya memerlukan kapasitas, bukan performa.
Jika Anda memerlukan performa yang tinggi, mulailah melihat opsi SSD. Disk SSD persistent
menawarkan redundansi data karena data di tiap persistent disk didistribusikan ke beberapa disk fisik.
SSD lokal menyediakan performa yang lebih tinggi tetapi tanpa redundansi data. Terakhir, disk RAM
sangat tidak stabil, namun menyediakan performa tertinggi. Layaknya terdapat limit pada jumlah SSD
lokal yang dapat Anda pasang ke VM, terdapat pula limit pada jumlah persistent disk yang dapat
dipasang ke VM. Seperti yang diilustrasikan dalam tabel ini, batas ini bergantung pada jumlah inti VM.
Misalnya, jika mesin Anda memiliki 8 inti atau lebih, Anda dapat memasang maksimal 128 disk. Jadi,
Anda dapat membuat jumlah kapasitas yang sangat besar untuk satu host. Apa Anda ingat perbedaan
kecil saat saya memberi tahu Anda bahwa throughput dibatasi oleh jumlah inti yang Anda miliki?
Throughput itu juga berbagi bandwidth yang sama dengan skala ini. Jadi, jika Anda berencana
menghasilkan throughput berjumlah sangat besar, throughput Anda juga akan bersaing dengan
throughput egress atau ingress jaringan. Jadi, ingatlah hal itu khususnya jika Anda akan menambah
jumlah drive yang terpasang ke mesin virtual. Ada banyak perbedaan antara harddisk fisik di komputer
dan persistent disk, yang pada dasarnya berupa perangkat jaringan virtual. Pertama-tama, jika Anda
ingat, pada disk hardware komputer biasa, Anda harus melakukan partisi. Pada dasarnya, Anda memiliki
drive dan Anda membuat satu bagian untuk sistem operasi agar memiliki kapasitasnya sendiri.

Jika ingin menambah kapasitas, Anda harus mempartisi ulang, dan jika Anda ingin melakukan
perubahan, Anda mungkin harus memformat ulang. Jika menginginkan redundansi, Anda dapat
membuat array disk yang redundan, dan jika menginginkan enkripsi, Anda perlu mengenkripsi file
sebelum menuliskan file ke disk.

Dengan persistent disk dari cloud, banyak hal yang sangat berbeda karena semua pengelolaan
ditangani untuk Anda di satu backend. Anda cukup menambah disk dan menyesuaikan ukuran sistem file
karena disk adalah perangkat jaringan virtual. Redundansi & layanan snapshot sudah ada, dan disk
dienkripsi secara otomatis. Anda bahkan dapat menggunakan kunci Anda sendiri, dan itu akan
memastikan tidak ada pihak yang dapat mengakses data kecuali Anda.
-) Common Compute Engine actions

Now that we have covered all the different compute, image and disk options, let's
look at some common actions that you can perform with Compute Engine. One common action
might be moving an instance to a new zone. For example, you might do so for geographical
reasons or because a zone is deprecated. If you move your instance within the same region, you
can automate the move by using the gcloud compute instances move command. If you move
your instance to a different region, you need to manually do so by following the process outlined
here. This involves making a snapshot of all persistent disks, and creating new disks in the
destination zone from that snapshot. Next, you create the new VM in the destination zone and
attach the new persistent disks, assign a static IP and update any references to the VM. Finally,
you delete the original VM, its disks and the snapshot. Speaking of snapshots, let's take a closer
look at these. Snapshots have many use cases. For example, they can be used to backup critical
data into a durable storage solution to meet application, availability and recovery requirements.
These snapshots are stored in cloud storage, which we'll cover in a later course of the
specialization. Snapshots can also be used to migrate data between zones. I just discussed this
when going over the manual process of moving an instance between two regions, but this can
also be used to simply transfer data from one zone to another. For example, you might want to
minimize latency by migrating data to a drive that can be locally attached in the zone where it is
used. Which brings me to another snapshot use case of transferring data to a different disk type.
For example, if you want to improve disk performance, you could use a snapshot to transfer data
from a standard HDD persistent disk to a SSD persistent disk. Now that I've covered some of
these snapshot use cases, let's explore the concept of a disk snapshot. First of all, this slide is
titled persistent disk snapshots because snapshots are available only to persistent disks and not to
local SSDs. Snapshots are different from public images and custom images, which are used
primarily to create instances or configure instance templates, in that snapshots are useful for
periodic backup of the data on your persistent disks. Snapshots are incremental and automatically
compressed, so you can create regular snapshots on a persistent disk faster and at a much lower
cost than if you regularly created a full image of the disk. As we saw with the previous examples,
snapshots can be restored to a new persistent disk allowing for a move to a new zone. Before
taking a disk snapshot, you should prepare the persistent disk. You can create a snapshot of a
persistent disk even while your applications write data to that disk. However, I recommend
freezing or unmounting the file system before you take a snapshot. This is the safest and most
reliable way to ensure that your disk buffers are cleared which improves snapshot consistency.
Specifically, when connected to your instance using SSH, stop any applications that are reading
or writing data to the persistent disk and either freeze a file system or unmount the file system.
To freeze, use the command, sudo fsfreeze and to unmount, use sudo unmount as shown on the
slide. Another common compute action is to resize your persistent disk. The main benefit of
increasing storage capacity is to improve I/O performance as illustrated in this table. This can be
achieved while the disk is attached to a running VM without having to create a snapshot. Now,
while you can grow disks in size, you can never shrink them, so do keep this in mind.