0 - en to id-ID translation catalogue (369 entries)

en: Preseeding
id-ID: Prabibit

en: Monitoring
id-ID: Pemantauan

en: Virtualization
id-ID: Virtualisasi

en: Advanced Administration
id-ID: Administrasi Tingkat Lanjut

en: This chapter revisits some aspects we already described, with a different perspective: instead of installing one single computer, we will study mass-deployment systems; instead of creating RAID or LVM volumes at install time, we'll learn to do it by hand so we can later revise our initial choices. Finally, we will discuss monitoring tools and virtualization techniques. As a consequence, this chapter is more particularly targeting professional administrators, and focuses somewhat less on individuals responsible for their home network.
id-ID: Bab ini meninjau kembali beberapa aspek yang telah kami uraikan, dengan perspektif yang berbeda: alih-alih memasang pada sebuah komputer, kita akan mempelajari sistem deployment masal; alih-alih membuat volume RAID atau LVM pada saat instalasi, kita akan belajar melakukannya secara manual sehingga nanti kita dapat merevisi pilihan awal kita. Akhirnya, kita akan mendiskusikan perkakas pemantauan dan teknik virtualisasi. Sebagai konsekuensinya, bab ini secara lebih khusus menarget para administrator profesional, and sedikit kurang brfokus pada para individu yang bertanggungjawab atas jaringan rumahan mereka.

en: RAID and LVM
id-ID: RAID dan LVM

en: RAID and LVM are both techniques to abstract the mounted volumes from their physical counterparts (actual hard-disk drives or partitions thereof); the former ensures the security and availability of the data in case of hardware failure by introducing redundancy, the latter makes volume management more flexible and independent of the actual size of the underlying disks. In both cases, the system ends up with new block devices, which can be used to create filesystems or swap space, without necessarily having them mapped to one physical disk. RAID and LVM come from quite different backgrounds, but their functionality can overlap somewhat, which is why they are often mentioned together.
id-ID: RAID dan LVM adalah teknik untuk mengabstrakkan volume yang dikait dari pasangan fisik mereka (yaitu hard disk atau partisi); yang pertama memastikan keamanan dan ketersediaan data dari kegagalan perangkat keras dengan memperkenalkan redundansi, yang belakangan membuat manajemen volume lebih luwes dan tak bergantung kepada ukuran sebenarnya dari disk yang mendasarinya. Dalam kedua kasus, sistem pada akhirnya mendapat perangkat blok baru, yang dapat dipakai untuk membuat sistem berkas atau ruang swap, tanpa perlu mereka dipetakan ke satu disk fisik. RAID dan LVM datang dari latar belakang yang cukup berbeda, tapi fungsionalitas mereka sebagian dapat bertumpang tindih, sehingga mereka sering disinggung bersama-sama.

en: <emphasis>PERSPECTIVE</emphasis> Btrfs combines LVM and RAID
id-ID: <emphasis>PERSPEKTIF</emphasis> Btrfs menggabung LVM dan RAID

en: Among the noteworthy features are the ability to take a snapshot of a filesystem tree at any point in time. This snapshot copy doesn't initially use any disk space, the data only being duplicated when one of the copies is modified. The filesystem also handles transparent compression of files, and checksums ensure the integrity of all stored data.
id-ID: Diantara fitur yang menarik adalah kemampuan membuat snapshot dari suatu pohon sistem berkas pada sebarang waktu. Snapshot ini pada awalnya tak memakai sebarang ruang disk, data hanya diduplikasi ketika satu dari salinan-salinan dimodifikasi. Sistem berkas juga menangani kompresi transparan dari berkas, dan checksum memastikan integritas dari semua data yang disimpan.

en: In both the RAID and LVM cases, the kernel provides a block device file, similar to the ones corresponding to a hard disk drive or a partition. When an application, or another part of the kernel, requires access to a block of such a device, the appropriate subsystem routes the block to the relevant physical layer. Depending on the configuration, this block can be stored on one or several physical disks, and its physical location may not be directly correlated to the location of the block in the logical device.
id-ID: Pada kedua kasus RAID dan LVM, kernel menyediakan suatu berkas perangkat blok, mirip dengan yang berkaitan dengan suatu hard disk atau suatu partisi. Ketika suatu aplikasi, atau bagian lain dari kernel, meminta akses ke suatu blok dari perangkat seperti itu, subsistem yang sesuai mengarahkan blok ke lapisan fisik yang relevan. Bergantung kepada konfigurasi, blok ini dapat disimpan pada satu atau beberapa disk fisik, dan lokasi fisiknya mungkin tak berkorelasi langsung ke lokasi blok dalam perangkat lojik.

en: Software RAID
id-ID: RAID Perangkat Lunak

en: RAID means <emphasis>Redundant Array of Independent Disks</emphasis>. The goal of this system is to prevent data loss and ensure availability in case of hard disk failure. The general principle is quite simple: data are stored on several physical disks instead of only one, with a configurable level of redundancy. Depending on this amount of redundancy, and even in the event of an unexpected disk failure, data can be losslessly reconstructed from the remaining disks.
id-ID: RAID adalah <emphasis>Redundant Array of Independent Disks</emphasis> (larik redundan dari disk-disk independen). Tujuan dari sistem ini adalah untuk mencegah kehilangan data dan memastikan ketersediaan dalam kasus kegagalan hard disk. Prinsip umumnya cukup sederhana: data disimpan pada beberapa disk fisik alih-alih hanya satu, dengan tingkat redundansi yang dapat dikonfigurasi. Bergantung kepada banyaknya redundansi ini, dan bahkan dalam kejadian kegagalan disk yang tak terduga, data dapat direkonstruksi tanpa adanya kehilangan dari disk sisanya.

en: <emphasis>CULTURE</emphasis> <foreignphrase>Independent</foreignphrase> or <foreignphrase>inexpensive</foreignphrase>?
id-ID: <emphasis>KULTUR</emphasis> <foreignphrase>Independen</foreignphrase> atau <foreignphrase>tidak mahal</foreignphrase>?

en: The I in RAID initially stood for <emphasis>inexpensive</emphasis>, because RAID allowed a drastic increase in data safety without requiring investing in expensive high-end disks. Probably due to image concerns, however, it is now more customarily considered to stand for <emphasis>independent</emphasis>, which doesn't have the unsavory flavor of cheapness.
id-ID: I dalam RAID pada awalnya merupakan singkatan dari <emphasis>inexpensive (tidak mahal)</emphasis>, karena RAID memungkinkan kenaikan drastis keselamatan data tanpa memerlukan investasi disk canggih yang mahal. Namun mungkin karena masalah citra, kini lebih umum dianggap singkatan dari <emphasis>independen</emphasis>, yang tak membawa kesan murahan yang tak menarik.

en: RAID can be implemented either by dedicated hardware (RAID modules integrated into SCSI or SATA controller cards) or by software abstraction (the kernel). Whether hardware or software, a RAID system with enough redundancy can transparently stay operational when a disk fails; the upper layers of the stack (applications) can even keep accessing the data in spite of the failure. Of course, this “degraded mode” can have an impact on performance, and redundancy is reduced, so a further disk failure can lead to data loss. In practice, therefore, one will strive to only stay in this degraded mode for as long as it takes to replace the failed disk. Once the new disk is in place, the RAID system can reconstruct the required data so as to return to a safe mode. The applications won't notice anything, apart from potentially reduced access speed, while the array is in degraded mode or during the reconstruction phase.
id-ID: RAID dapat diwujudkan baik oleh perangkat keras khusus (modul RAID yang terintegrasi ke dalam kartu pengendali SCSI atau SATA) atau oleh abstraksi perangkat lunak (kernel). Apakah perangkat keras atau perangkat lunak, sistem RAID dengan redundansi yang cukup bisa secara transparan tetap operasional ketika sebuah disk gagal; lapisan atas tumpukan (aplikasi) bahkan dapat tetap mengakses data terlepas dari kegagalan. Tentu saja, "mode terdegradasi" ini dapat memiliki dampak pada kinerja, dan redundansi berkurang, sehingga kegagalan disk lebih lanjut dapat mengakibatkan kehilangan data. Dalam prakteknya, oleh karena itu, kita akan berusaha untuk hanya berada dalam mode terdegradasi ini selama diperlukannya untuk menggantikan disk yang gagal. Sekali disk baru terpasang sistem RAID dapat merekonstruksi data yang dibutuhkan untuk kembali ke mode aman. Aplikasi tidak akan melihat apa-apa, selain kecepatan akses berpotensi berkurang, sementara larik ada dalam mode terdegradasi atau selama fase rekonstruksi.

en: When RAID is implemented by hardware, its configuration generally happens within the BIOS setup tool, and the kernel will consider a RAID array as a single disk, which will work as a standard physical disk, although the device name may be different (depending on the driver).
id-ID: Ketika RAID diimplementasikan oleh perangkat keras, konfigurasinya umumnya terjadi dalam alat konfigurasi BIOS, dan kernel akan menganggap sebuah array RAID sebagai satu disk, yang akan bekerja sebagai disk fisik standar, meskipun nama perangkat mungkin berbeda (tergantung pada driver).

en: We only focus on software RAID in this book.
id-ID: Kami hanya berfokus pada RAID perangkat lunak dalam buku ini.

en: Different RAID Levels
id-ID: Tingkat-tingkat RAID

en: RAID is actually not a single system, but a range of systems identified by their levels; the levels differ by their layout and the amount of redundancy they provide. The more redundant, the more failure-proof, since the system will be able to keep working with more failed disks. The counterpart is that the usable space shrinks for a given set of disks; seen the other way, more disks will be needed to store a given amount of data.
id-ID: RAID sebenarnya buka satu sistem, tapi berbagai sistem yang diidentifikasi oleh tingkat mereka; tingkat-tingkat itu dibedakan oleh tata letak dan banyaknya redundansi yang mereka sediakan. Semakin banyak redundan, semakin kebal kegagalan, karena sistem akan dapat terus bekerja dengan lebih banyak disk yang gagal. Kekurangannya adalah bahwa ruang yang dapat digunakan menyusut untuk satu set disk tertentu; dilihat dengan cara lain, akan diperlukan lebih banyak disk untuk menyimpan sejumlah data yang diberikan.

en: Linear RAID
id-ID: RAID Linier

en: Even though the kernel's RAID subsystem allows creating “linear RAID”, this is not proper RAID, since this setup doesn't involve any redundancy. The kernel merely aggregates several disks end-to-end and provides the resulting aggregated volume as one virtual disk (one block device). That is about its only function. This setup is rarely used by itself (see later for the exceptions), especially since the lack of redundancy means that one disk failing makes the whole aggregate, and therefore all the data, unavailable.
id-ID: Meskipun subsistem RAID kernel memungkinkan menciptakan "linear RAID", ini bukan RAID yang benar, karena konfigurasi ini tidak melibatkan redundansi apapun. Kernel hanya mengumpulkan beberapa disk end-to-end dan menyediakan volume agregat yang dihasilkan sebagai satu disk virtual (satu perangkat blok). Itu adalah satu-satunya fungsinya. Konfigurasi ini jarang digunakan sendirian (lihat nanti untuk pengecualian), terutama karena kurangnya redundansi berarti bahwa salah satu disk gagal membuat seluruh agregat, dan karena itu semua data, tidak tersedia.

en: This level doesn't provide any redundancy either, but disks aren't simply stuck on end one after another: they are divided in <emphasis>stripes</emphasis>, and the blocks on the virtual device are stored on stripes on alternating physical disks. In a two-disk RAID-0 setup, for instance, even-numbered blocks of the virtual device will be stored on the first physical disk, while odd-numbered blocks will end up on the second physical disk.
id-ID: Tingkat ini tidak menyediakan redundansi apapun, tapi disk-disk tidak hanya sekadar dilekatkan satu di akhir yang lain: mereka dibagi dalam <emphasis>stripe</emphasis>, dan blok-blok di perangkat virtual disimpan dalam stripe di disk-disk fisik yang berbeda-beda. Dalam setup RAID-0 dua-disk, misalnya, blok bernomor genap dari perangkat virtual akan disimpan pada disk fisik pertama, sementara blok bernomor ganjil akan berakhir pada disk fisik kedua.

en: This system doesn't aim at increasing reliability, since (as in the linear case) the availability of all the data is jeopardized as soon as one disk fails, but at increasing performance: during sequential access to large amounts of contiguous data, the kernel will be able to read from both disks (or write to them) in parallel, which increases the data transfer rate. The disks are utilized entirely by the RAID device, so they should have the same size not to lose performance.
id-ID: Sistem ini tidak bertujuan meningkatkan keandalan, karena (seperti dalam kasus linier) ketersediaan semua data hancur begitu satu disk gagal, tetapi meningkatkan kinerja: selama akses berurutan ke sejumlah besar data yang berdekatan, kernel akan mampu membaca dari kedua disk (atau menulis ke mereka) secara paralel, yang akan meningkatkan laju transfer data. Disk dimanfaatkan sepenuhnya oleh peranti RAID, sehingga mereka mestinya memiliki ukuran yang sama agar tidak kehilangan kinerja.

en: RAID-0 use is shrinking, its niche being filled by LVM (see later).
id-ID: Penggunaan RAID-0 berkurang, ceruknya sedang diisi oleh LVM (lihat lagi nanti).

en: This level, also known as “RAID mirroring”, is both the simplest and the most widely used setup. In its standard form, it uses two physical disks of the same size, and provides a logical volume of the same size again. Data are stored identically on both disks, hence the “mirror” nickname. When one disk fails, the data is still available on the other. For really critical data, RAID-1 can of course be set up on more than two disks, with a direct impact on the ratio of hardware cost versus available payload space.
id-ID: Tingkat ini, juga dikenal sebagai "RAID mirroring", adalah yang paling sederhana dan setup yang paling banyak digunakan. Dalam bentuk standar, menggunakan dua disk fisik berukuran sama, dan memberikan volume logis berukuran yang sama lagi. Data disimpan identik pada disk kedua, maka dijuluki "mirror (cermin)". Ketika satu disk gagal, data ini masih tersedia di yang lain. Untuk data yang benar-benar penting, RAID-1 dapat tentu saja diatur pada disk yang lebih dari dua, dengan dampak langsung pada rasio biaya perangkat keras versus ruang muatan yang tersedia.

en: <emphasis>NOTE</emphasis> Disks and cluster sizes
id-ID: <emphasis>CATATAN</emphasis> Ukuran klaster dan disk

en: If two disks of different sizes are set up in a mirror, the bigger one will not be fully used, since it will contain the same data as the smallest one and nothing more. The useful available space provided by a RAID-1 volume therefore matches the size of the smallest disk in the array. This still holds for RAID volumes with a higher RAID level, even though redundancy is stored differently.
id-ID: Jika dua disk dengan ukuran yang berbeda diatur dalam cermin, yang lebih besar tidak akan sepenuhnya digunakan, karena itu akan berisi data yang sama seperti yang terkecil dan tidak lebih. Ruang tersedia yang berguna yang disediakan oleh volume RAID-1 karena itu cocok dengan ukuran disk terkecil dalam array. Ini masih berlaku untuk volume RAID dengan tingkat yang lebih tinggi, meskipun redundansi disimpan dengan cara berbeda.

en: It is therefore important, when setting up RAID arrays (except for RAID-0 and “linear RAID”), to only assemble disks of identical, or very close, sizes, to avoid wasting resources.
id-ID: Karena itu penting, ketika menyiapkan array RAID (kecuali RAID-0 dan "linear RAID"), untuk menyusun hanya disk-disk berukuran identik atau sangat dekat, untuk menghindari membuang-buang sumber daya.

en: <emphasis>NOTE</emphasis> Spare disks
id-ID: <emphasis>CATATAN</emphasis> Disk cadangan

en: RAID levels that include redundancy allow assigning more disks than required to an array. The extra disks are used as spares when one of the main disks fails. For instance, in a mirror of two disks plus one spare, if one of the first two disks fails, the kernel will automatically (and immediately) reconstruct the mirror using the spare disk, so that redundancy stays assured after the reconstruction time. This can be used as another kind of safeguard for critical data.
id-ID: Tingkat RAID yang mencakup redundansi memungkinkan menugaskan disk lebih banyak dari yang dibutuhkan untuk array. Tambahan disk digunakan sebagai suku cadang ketika salah satu disk utama gagal. Sebagai contoh, cermin dua disk ditambah cadangan satu, jika salah satu disk dari dua pertama gagal, kernel akan otomatis (dan segera) merekonstruksi cermin menggunakan disk cadangan, sehingga redundansi tetap terjamin setelah masa rekonstruksi. Ini dapat digunakan sebagai jenis lain dari perlindungan bagi data penting.

en: One would be forgiven for wondering how this is better than simply mirroring on three disks to start with. The advantage of the “spare disk” configuration is that the spare disk can be shared across several RAID volumes. For instance, one can have three mirrored volumes, with redundancy assured even in the event of one disk failure, with only seven disks (three pairs, plus one shared spare), instead of the nine disks that would be required by three triplets.
id-ID: Kita akan dimaafkan untuk bertanya-tanya bagaimana hal ini lebih baik daripada sekadar mencerminkan pada tiga disk di awal. Keuntungan dari konfigurasi "disk cadangan" adalah bahwa disk cadangan dapat dipakai bersama pada beberapa volume RAID. Sebagai contoh, kita dapat memiliki tiga volume tercermin, dengan redundansi yang dijamin bahkan jika salah satu kegagalan disk, hanya dengan tujuh disk (tiga pasang, ditambah satu cadangan bersama), bukan sembilan disk yang akan dibutuhkan oleh tiga buah kembar tiga.

en: This RAID level, although expensive (since only half of the physical storage space, at best, is useful), is widely used in practice. It is simple to understand, and it allows very simple backups: since both disks have identical contents, one of them can be temporarily extracted with no impact on the working system. Read performance is often increased since the kernel can read half of the data on each disk in parallel, while write performance isn't too severely degraded. In case of a RAID-1 array of N disks, the data stays available even with N-1 disk failures.
id-ID: Tingkat RAID ini, walaupun mahal (karena hanya separuh dari ruang penyimpanan fisik, dalam keadaan terbaik, berguna), secara luas digunakan dalam praktek. Hal ini mudah untuk dipahami, dan memungkinkan cadangan yang sangat sederhana: karena disk kedua memiliki isi yang identik, salah satu dari mereka dapat sementara diekstraksi dengan tidak berdampak pada sistem yang bekerja. Kinerja baca sering meningkat karena kernel bisa membaca setengah dari data pada setiap disk secara paralel, sementara kinerja tulis tidak terlalu turun parah. Dalam sebuah array RAID-1 N disk, data tetap tersedia bahkan dengan N-1 disk gagal.

en: This RAID level, not widely used, uses N disks to store useful data, and an extra disk to store redundancy information. If that disk fails, the system can reconstruct its contents from the other N. If one of the N data disks fails, the remaining N-1 combined with the “parity” disk contain enough information to reconstruct the required data.
id-ID: Tingkat RAID ini, tidak banyak dipakai, menggunakan N disk untuk menyimpan data yang berguna, dan disk tambahan untuk menyimpan informasi redundansi. Jika disk itu gagal, sistem dapat merekonstruksi isinya dari N yang lain. Jika salah satu dari N disk data gagal, N-1 sisa yang dikombinasikan dengan disk "paritas" berisi cukup informasi untuk merekonstruksi data yang dibutuhkan.

en: RAID-4 isn't too expensive since it only involves a one-in-N increase in costs and has no noticeable impact on read performance, but writes are slowed down. Furthermore, since a write to any of the N disks also involves a write to the parity disk, the latter sees many more writes than the former, and its lifespan can shorten dramatically as a consequence. Data on a RAID-4 array is safe only up to one failed disk (of the N+1).
id-ID: RAID-4 tidak terlalu mahal karena itu hanya melibatkan peningkatan biaya satu-dari-N dan tidak memiliki dampak yang terlihat pada kinerja baca, tapi penulisan melambat. Selanjutnya, karena menulis ke salah satu dari N disk juga melibatkan menulis ke disk paritas, yang terakhir melihat menulis lebih banyak daripada yang pertama, dan usia pakainya dapat memendek secara dramatis sebagai akibatnya. Data pada array RAID-4 aman hanya sampai dengan satu disk gagal (dari N+1).

en: RAID-5 addresses the asymmetry issue of RAID-4: parity blocks are spread over all of the N+1 disks, with no single disk having a particular role.
id-ID: RAID-5 menjawab masalah asimetri dari RAID-4: blok paritas disebar ke seluruh N+1 disk, tanpa ada satu disk yang memiliki peran tertentu.

en: Read and write performance are identical to RAID-4. Here again, the system stays functional with up to one failed disk (of the N+1), but no more.
id-ID: Kinerja baca dan tulis identik dengan RAID-4. Di sini, sistem tetap berfungsi bila satu disk (dari N+1) gagal, tapi tak boleh lebih.

en: RAID-6 can be considered an extension of RAID-5, where each series of N blocks involves two redundancy blocks, and each such series of N+2 blocks is spread over N+2 disks.
id-ID: RAID-6 dapat dianggap perluasan dari RAID-5, dimana setiap seri N blok melibatkan dua blok redundansi, dan setiap seri N+2 blok disebar ke N+2 disk.

en: This RAID level is slightly more expensive than the previous two, but it brings some extra safety since up to two drives (of the N+2) can fail without compromising data availability. The counterpart is that write operations now involve writing one data block and two redundancy blocks, which makes them even slower.
id-ID: Tingkat RAID ini sedikit lebih mahal daripada dua sebelumnya, tapi itu membawa beberapa keamanan tambahan karena sampai dengan dua drive (dari N+2) bisa gagal tanpa mengorbankan ketersediaan data. Kekurangannya adalah bahwa sekarang operasi tulis melibatkan menulis satu blok data dan dua blok redundansi, yang membuat mereka lebih lambat lagi.

en: This isn't strictly speaking, a RAID level, but a stacking of two RAID groupings. Starting from 2×N disks, one first sets them up by pairs into N RAID-1 volumes; these N volumes are then aggregated into one, either by “linear RAID” or (increasingly) by LVM. This last case goes farther than pure RAID, but there is no problem with that.
id-ID: Ini secara presisi bukan tingkat RAID, tapi penumpukan dua pengelompokan RAID. Mulai dari 2×N disk, kita pertama kali menyiapkan pasangan-pasangan ke N volume RAID-1; N volume ini kemudian dikumpulkan menjadi satu, baik memakai "linear RAID" atau (semakin banyak) memakai LVM. Kasus terakhir ini di luar RAID murni, tapi tidak ada masalah dengan itu.

en: RAID-1+0 can survive multiple disk failures: up to N in the 2×N array described above, provided that at least one disk keeps working in each of the RAID-1 pairs.
id-ID: RAID-1+0 dapat bertahan dari beberapa disk gagal: sampai N dalam array 2×N yang dijelaskan di atas, asal bahwa setidaknya satu disk tetap bekerja di setiap pasangan RAID-1.

en: <emphasis>GOING FURTHER</emphasis> RAID-10
id-ID: <emphasis>LEBIH JAUH</emphasis> RAID-10

en: RAID-10 is generally considered a synonym of RAID-1+0, but a Linux specificity makes it actually a generalization. This setup allows a system where each block is stored on two different disks, even with an odd number of disks, the copies being spread out along a configurable model.
id-ID: RAID-10 umumnya dianggap sebagai sinonim dari RAID-1+0, namun kekhususan Linux membuat itu sebenarnya generalisasi. Konfigurasi ini memungkinkan sistem dimana setiap blok disimpan pada dua disk berbeda, bahkan dengan cacah disk ganjil, salinan disebar ke model yang dapat dikonfigurasi.

en: Performances will vary depending on the chosen repartition model and redundancy level, and of the workload of the logical volume.
id-ID: Kinerja akan bervariasi tergantung pada model repartisi dan tingkat redundansi yang dipilih, dan beban kerja dari volume logis.

en: Obviously, the RAID level will be chosen according to the constraints and requirements of each application. Note that a single computer can have several distinct RAID arrays with different configurations.
id-ID: Jelas, tingkat RAID akan dipilih sesuai dengan kendala dan persyaratan setiap aplikasi. Perhatikan bahwa satu komputer dapat memiliki beberapa array RAID yang berbeda dengan konfigurasi yang berbeda.

en: Setting up RAID
id-ID: Menyiapkan RAID

en: Setting up RAID volumes requires the <emphasis role="pkg">mdadm</emphasis> package; it provides the <command>mdadm</command> command, which allows creating and manipulating RAID arrays, as well as scripts and tools integrating it to the rest of the system, including the monitoring system.
id-ID: Menyiapkan volume RAID memerlukan paket <emphasis role="pkg">mdadm</emphasis>; ini menyediakan perintah <command>mdadm</command>, yang memungkinkan membuat dan memanipulasi array RAID, maupun skrip dan alat-alat yang mengintegrasikan ke seluruh sistem, termasuk sistem pemantauan.

en: Our example will be a server with a number of disks, some of which are already used, the rest being available to setup RAID. We initially have the following disks and partitions:
id-ID: Contoh kita akan menjadi server dengan sejumlah disk, beberapa di antaranya sudah digunakan, sisanya tersedia untuk menyiapkan RAID. Kita awalnya memiliki disk dan partisi sebagai berikut:

en: the <filename>sdb</filename> disk, 4 GB, is entirely available;
id-ID: disk <filename>sdb</filename>, 4 GB, sepenuhnya tersedia;

en: the <filename>sdc</filename> disk, 4 GB, is also entirely available;
id-ID: disk <filename>sdc</filename>, 4 GB, ini juga sepenuhnya tersedia;

en: on the <filename>sdd</filename> disk, only partition <filename>sdd2</filename> (about 4 GB) is available;
id-ID: pada disk <filename>sdd</filename>, hanya partisi <filename>sdd2</filename> (sekitar 4 GB) tersedia;

en: finally, a <filename>sde</filename> disk, still 4 GB, entirely available.
id-ID: akhirnya, disk <filename>sde</filename>, masih 4 GB, sepenuhnya tersedia.

en: <emphasis>NOTE</emphasis> Identifying existing RAID volumes
id-ID: <emphasis>CATATAN</emphasis> Mengidentifikasi volume RAID yang ada

en: The <filename>/proc/mdstat</filename> file lists existing volumes and their states. When creating a new RAID volume, care should be taken not to name it the same as an existing volume.
id-ID: Berkas <filename>/proc/mdstat</filename> memuat daftar volume yang ada dan keadaan mereka. Ketika membuat volume RAID baru, mesti hati-hati untuk tidak memberi nama yang sama dengan volume yang sudah ada.

en: We're going to use these physical elements to build two volumes, one RAID-0 and one mirror (RAID-1). Let's start with the RAID-0 volume:
id-ID: Kita akan menggunakan unsur-unsur fisik ini untuk membangun dua volume, satu RAID-0 dan satu cermin (RAID-1). Mari kita mulai dengan volume RAID-0:

en: The <command>mdadm --create</command> command requires several parameters: the name of the volume to create (<filename>/dev/md*</filename>, with MD standing for <foreignphrase>Multiple Device</foreignphrase>), the RAID level, the number of disks (which is compulsory despite being mostly meaningful only with RAID-1 and above), and the physical drives to use. Once the device is created, we can use it like we'd use a normal partition, create a filesystem on it, mount that filesystem, and so on. Note that our creation of a RAID-0 volume on <filename>md0</filename> is nothing but coincidence, and the numbering of the array doesn't need to be correlated to the chosen amount of redundancy. It is also possible to create named RAID arrays, by giving <command>mdadm</command> parameters such as <filename>/dev/md/linear</filename> instead of <filename>/dev/md0</filename>.
id-ID: Perintah <command>mdadm --create</command> memerlukan beberapa parameter: nama volume yang akan dibuat (<filename>/dev/md*</filename>, dengan MD singkatan dari <foreignphrase>Multiple Devices</foreignphrase>), tingkat RAID, cacah disk (yang wajib meskipun sebagian besar bermakna hanya dengan RAID-1 dan di atasnya), dan drive fisik yang akan digunakan. Setelah perangkat dibuat, kita dapat menggunakannya seperti kita akan menggunakan sebuah partisi normal, membuat sebuah sistem berkas di atasnya, mengait sistem berkas itu, dan sebagainya. Perhatikan bahwa penciptaan kita atas suatu volume RAID-0 pada <filename>md0</filename> hanya kebetulan, dan penomoran array tidak perlu berkorelasi dengan pilihan banyaknya redundansi. Hal ini juga memungkinkan untuk membuat array RAID bernama, dengan memberikan parameter <command>mdadm</command> seperti misalnya <filename>/dev/md/linear</filename> bukan <filename>/dev/md0</filename>.

en: Creation of a RAID-1 follows a similar fashion, the differences only being noticeable after the creation:
id-ID: Penciptaan RAID-1 mengikuti cara yang sama, perbedaannya hanya menjadi terlihat setelah penciptaan:

en: <emphasis>TIP</emphasis> RAID, disks and partitions
id-ID: <emphasis>TIPS</emphasis> RAID, disk, dan partisi

en: A few remarks are in order. First, <command>mdadm</command> notices that the physical elements have different sizes; since this implies that some space will be lost on the bigger element, a confirmation is required.
id-ID: Beberapa komentar perlu disinggung. Pertama, <command>mdadm</command> tahu bahwa elemen-elemen fisik memiliki ukuran yang berbeda; karena hal ini menyiratkan bahwa sebagian ruang akan hilang pada elemen yang lebih besar, konfirmasi diperlukan.

en: More importantly, note the state of the mirror. The normal state of a RAID mirror is that both disks have exactly the same contents. However, nothing guarantees this is the case when the volume is first created. The RAID subsystem will therefore provide that guarantee itself, and there will be a synchronization phase as soon as the RAID device is created. After some time (the exact amount will depend on the actual size of the disks…), the RAID array switches to the “active” or “clean” state. Note that during this reconstruction phase, the mirror is in a degraded mode, and redundancy isn't assured. A disk failing during that risk window could lead to losing all the data. Large amounts of critical data, however, are rarely stored on a freshly created RAID array before its initial synchronization. Note that even in degraded mode, the <filename>/dev/md1</filename> is usable, and a filesystem can be created on it, as well as some data copied on it.
id-ID: Lebih penting lagi, perhatikan keadaan cermin. Keadaan normal dari suatu cermin RAID adalah bahwa kedua disk memiliki isi yang tepat sama. Namun, tidak ada yang menjamin ini ketika volume pertama kali dibuat. Subsistem RAID karena itu akan memberikan jaminan itu sendiri, dan akan ada tahap sinkronisasi segera setelah perangkat RAID dibuat. Setelah beberapa waktu (lama persisnya akan tergantung pada ukuran sebenarnya dari disk...), array RAID berpindah ke keadaan "aktif" atau "bersih". Perhatikan bahwa selama fase rekonstruksi ini, cermin ada dalam mode terdegradasi, dan redundansi tidak dijamin. Sebuah disk yang gagal selama jendela risiko itu bisa mengakibatkan kehilangan semua data. Namun, sejumlah besar data penting, jarang disimpan pada sebuah array RAID yang baru dibuat sebelum sinkronisasi awalnya. Catat bahwa bahkan dalam mode terdegradasi, <filename>/dev/md1</filename> dapat digunakan, dan sebuah sistem berkas dapat dibuat di atasnya, maupun data dapat disalin ke sana.

en: <emphasis>TIP</emphasis> Starting a mirror in degraded mode
id-ID: <emphasis>TIPS</emphasis> Memulai mirror dalam mode terdegradasi

en: Sometimes two disks are not immediately available when one wants to start a RAID-1 mirror, for instance because one of the disks one plans to include is already used to store the data one wants to move to the array. In such circumstances, it is possible to deliberately create a degraded RAID-1 array by passing <filename>missing</filename> instead of a device file as one of the arguments to <command>mdadm</command>. Once the data have been copied to the “mirror”, the old disk can be added to the array. A synchronization will then take place, giving us the redundancy that was wanted in the first place.
id-ID: Kadang-kadang dua disk tidak tersedia seketika saat seseorang ingin memulai suatu cermin RAID-1, misalnya karena salah satu disk yang rencananya akan disertakan sudah digunakan untuk menyimpan data yang ingin dipindah ke array. Dalam keadaan seperti itu, dimungkinkan untuk sengaja menciptakan array RAID-1 yang terdegradasi dengan memberikan <filename>missing</filename>, bukan berkas perangkat sebagai salah satu argumen untuk <command>mdadm</command>. Setelah data telah disalin ke "cermin", disk lama dapat ditambahkan ke array. Sinkronisasi kemudian akan terjadi, memberikan kita redundansi yang diinginkan di awal.

en: <emphasis>TIP</emphasis> Setting up a mirror without synchronization
id-ID: <emphasis>TIPS</emphasis> Menyiapkan cermin tanpa sinkronisasi

en: RAID-1 volumes are often created to be used as a new disk, often considered blank. The actual initial contents of the disk is therefore not very relevant, since one only needs to know that the data written after the creation of the volume, in particular the filesystem, can be accessed later.
id-ID: Volume RAID-1 sering dibuat untuk digunakan sebagai disk baru, sering dianggap kosong. Isi awal sebenarnya dari disk ini karena itu tidak sangat relevan, karena hanya perlu diketahui bahwa data setelah penciptaan volume, khususnya sistem berkas, dapat diakses setelahnya.

en: One might therefore wonder about the point of synchronizing both disks at creation time. Why care whether the contents are identical on zones of the volume that we know will only be read after we have written to them?
id-ID: Karena itu orang mungkin bertanya-tanya tentang titik sinkronisasi kedua disk pada waktu penciptaan. Mengapa peduli apakah isi identik pada zona volume yang kita ketahui hanya dapat dibaca setelah kita telah menulis?

en: Fortunately, this synchronization phase can be avoided by passing the <literal>--assume-clean</literal> option to <command>mdadm</command>. However, this option can lead to surprises in cases where the initial data will be read (for instance if a filesystem is already present on the physical disks), which is why it isn't enabled by default.
id-ID: Untungnya, tahap sinkronisasi ini dapat dihindari dengan memberikan opsi <literal>--assume-clean</literal> untuk <command>mdadm</command>. Namun, pilihan ini dapat menyebabkan kejutan dalam kasus-kasus di mana data awal akan dibaca (misalnya jika sistem berkas tersebut sudah hadir pada disk fisik), itulah sebabnya itu tidak diaktifkan secara default.

en: Now let's see what happens when one of the elements of the RAID-1 array fails. <command>mdadm</command>, in particular its <literal>--fail</literal> option, allows simulating such a disk failure:
id-ID: Sekarang mari kita lihat apa yang terjadi ketika salah satu elemen array RAID-1 gagal. <command>mdadm</command>, khususnya opsi <literal>--fail</literal>, memungkinkan simulasi suatu kegagalan disk:

en: The contents of the volume are still accessible (and, if it is mounted, the applications don't notice a thing), but the data safety isn't assured anymore: should the <filename>sdd</filename> disk fail in turn, the data would be lost. We want to avoid that risk, so we'll replace the failed disk with a new one, <filename>sdf</filename>:
id-ID: Isi dari volume masih dapat diakses (dan, jika dipasang, aplikasi tidak menyadari apapun), tapi keselamatan data tidak dijamin lagi: seandainya <filename>sdd</filename> disk gagal bergantian, data akan hilang. Kami ingin menghindari risiko, jadi kami akan mengganti disk yang gagal dengan yang baru, <filename>sdf</filename>:

en: Here again, the kernel automatically triggers a reconstruction phase during which the volume, although still accessible, is in a degraded mode. Once the reconstruction is over, the RAID array is back to a normal state. One can then tell the system that the <filename>sde</filename> disk is about to be removed from the array, so as to end up with a classical RAID mirror on two disks:
id-ID: Di sini lagi, kernel secara otomatis memicu tahap rekonstruksi yang ketika berlangsung, meskipun volume masih dapat diakses, berada dalam mode terdegradasi. Setelah rekonstruksi berakhir, array RAID kembali ke keadaan normal. Kita kemudian dapat memberitahu ke sistem bahwa disk <filename>sde</filename> akan dihapus dari array, sehingga berakhir dengan RAID mirror klasik pada dua disk:

en: From then on, the drive can be physically removed when the server is next switched off, or even hot-removed when the hardware configuration allows hot-swap. Such configurations include some SCSI controllers, most SATA disks, and external drives operating on USB or Firewire.
id-ID: Selanjutnya drive dapat secara fisik dicabut saat server berikutnya dimatikan, atau bahkan dicabut saat menyala ketika konfigurasi hardware mengizinkan hot-swap. Konfigurasi tersebut termasuk beberapa pengendali SCSI, kebanyakan disk SATA, dan drive eksternal yang beroperasi pada USB atau Firewire.

en: Backing up the Configuration
id-ID: Mem-back up Konfigurasi

en: Backing up the configuration is therefore important, if only for reference. The standard way to do it is by editing the <filename>/etc/mdadm/mdadm.conf</filename> file, an example of which is listed here:
id-ID: Karena itu cadangan konfigurasi penting, walaupun hanya untuk referensi. Cara standar untuk melakukannya adalah dengan menyunting berkas <filename>/etc/mdadm/mdadm.conf</filename>, contohnya tercantum di sini:

en: <command>mdadm</command> configuration file
id-ID: berkas konfigurasi <command>mdadm</command>

en: One of the most useful details is the <literal>DEVICE</literal> option, which lists the devices where the system will automatically look for components of RAID volumes at start-up time. In our example, we replaced the default value, <literal>partitions containers</literal>, with an explicit list of device files, since we chose to use entire disks and not only partitions, for some volumes.
id-ID: Salah satu rincian paling berguna adalah opsi <literal>DEVICE</literal>, yang berisi daftar perangkat tempat sistem akan secara otomatis mencari komponen volume RAID saat start-up. Dalam contoh, kita menggantikan nilai default, <literal>partitions containers</literal>, dengan daftar eksplisit berkas perangkat, karena kita memilih untuk menggunakan seluruh disk dan tidak hanya partisi, untuk beberapa volume.

en: The last two lines in our example are those allowing the kernel to safely pick which volume number to assign to which array. The metadata stored on the disks themselves are enough to re-assemble the volumes, but not to determine the volume number (and the matching <filename>/dev/md*</filename> device name).
id-ID: Dua baris terakhir dalam contoh kita adalah yang memungkinkan kernel untuk secara aman memilih nomor volume yang ditetapkan ke array mana. Metadata yang tersimpan pada disk itu sendiri cukup untuk membangun kembali volume, tetapi tidak untuk menentukan nomor volume (dan nama perangkat <filename>/dev/md*</filename> yang cocok).

en: Fortunately, these lines can be generated automatically:
id-ID: Untungnya, baris-baris ini dapat dihasilkan secara otomatis:

en: The contents of these last two lines doesn't depend on the list of disks included in the volume. It is therefore not necessary to regenerate these lines when replacing a failed disk with a new one. On the other hand, care must be taken to update the file when creating or deleting a RAID array.
id-ID: Isi dari dua baris terakhir ini tidak tergantung pada daftar disk yang disertakan dalam volume. Maka tidak diperlukan untuk meregenerasi baris-baris ini ketika menggantikan disk gagal dengan yang baru. Di sisi lain, perawatan harus diambil untuk memperbarui berkas ketika membuat atau menghapus sebuah array RAID.

en: LVM, the <emphasis>Logical Volume Manager</emphasis>, is another approach to abstracting logical volumes from their physical supports, which focuses on increasing flexibility rather than increasing reliability. LVM allows changing a logical volume transparently as far as the applications are concerned; for instance, it is possible to add new disks, migrate the data to them, and remove the old disks, without unmounting the volume.
id-ID: LVM, <emphasis>Logical Volume Manager</emphasis>, adalah pendekatan lain untuk mengabstrakkan volume logis dari dukungan fisik mereka, yang berfokus pada peningkatan fleksibilitas daripada meningkatkan kehandalan. LVM dapat mengubah volume logis secara transparan bagi aplikasi; sebagai contoh, sangat mungkin untuk menambahkan disk baru, memigrasi data ke mereka, dan menghapus disk lama, tanpa melepas kait volume.

en: LVM Concepts
id-ID: Konsep LVM

en: This flexibility is attained by a level of abstraction involving three concepts.
id-ID: Fleksibilitas ini dicapai dengan tingkat abstraksi yang melibatkan tiga konsep.

en: First, the PV (<emphasis>Physical Volume</emphasis>) is the entity closest to the hardware: it can be partitions on a disk, or a full disk, or even any other block device (including, for instance, a RAID array). Note that when a physical element is set up to be a PV for LVM, it should only be accessed via LVM, otherwise the system will get confused.
id-ID: Pertama, PV (<emphasis>Physical Volume</emphasis>) adalah entitas terdekat dengan perangkat keras: itu bisa berupa partisi pada disk atau seluruh disk, atau bahkan perangkat blok lain (termasuk, sebagai contoh, sebuah array RAID). Perhatikan bahwa ketika sebuah elemen fisik diatur hingga menjadi PV untuk LVM, itu mesti hanya diakses melalui LVM, jika tidak sistem akan bingung.

en: A number of PVs can be clustered in a VG (<emphasis>Volume Group</emphasis>), which can be compared to disks both virtual and extensible. VGs are abstract, and don't appear in a device file in the <filename>/dev</filename> hierarchy, so there is no risk of using them directly.
id-ID: Sejumlah PV dapat dikumpulkan dalam VG (<emphasis>Volume Group</emphasis>), yang dapat dibandingkan dengan disk virtual dan extensible. VG abstrak, dan tidak muncul dalam perangkat berkas di hirarki <filename>/dev</filename>, sehingga tidak ada risiko menggunakan mereka secara langsung.

en: The third kind of object is the LV (<emphasis>Logical Volume</emphasis>), which is a chunk of a VG; if we keep the VG-as-disk analogy, the LV compares to a partition. The LV appears as a block device with an entry in <filename>/dev</filename>, and it can be used as any other physical partition can be (most commonly, to host a filesystem or swap space).
id-ID: Jenis ke tiga objek adalah LV (<emphasis>Logical Volume</emphasis>), yang berupa potongan dari suatu VG; jika kita memakai analogi VG-sebagai-disk, LV setara dengan partisi. LV muncul sebagai perangkat blok dengan entri di <filename>/dev</filename>, dan dapat digunakan seperti setiap partisi fisik lainnya dapat (paling sering, mewadahi sebuah sistem berkas atau ruang swap).

en: The important thing is that the splitting of a VG into LVs is entirely independent of its physical components (the PVs). A VG with only a single physical component (a disk for instance) can be split into a dozen logical volumes; similarly, a VG can use several physical disks and appear as a single large logical volume. The only constraint, obviously, is that the total size allocated to LVs can't be bigger than the total capacity of the PVs in the volume group.
id-ID: Yang penting adalah bahwa pemisahan VG ke LV sepenuhnya independen dari komponen fisiknya (PV). VG dengan hanya satu komponen fisik (disk misalnya) dapat dipisah menjadi selusin volume logis; demikian pula, sebuah VG dapat menggunakan beberapa disk fisik dan muncul sebagai satu volume logis yang besar. Satu-satunya kendala, jelas, adalah bahwa ukuran total yang dialokasikan untuk LV tidak bisa lebih dari total kapasitas dari PV dalam kelompok volume.

en: It often makes sense, however, to have some kind of homogeneity among the physical components of a VG, and to split the VG into logical volumes that will have similar usage patterns. For instance, if the available hardware includes fast disks and slower disks, the fast ones could be clustered into one VG and the slower ones into another; chunks of the first one can then be assigned to applications requiring fast data access, while the second one will be kept for less demanding tasks.
id-ID: Namun sering masuk akal untuk memiliki semacam keseragaman antara komponen fisik VG, dan untuk membagi VG menjadi volume logis yang akan memiliki pola penggunaan serupa. Misalnya, jika perangkat keras yang tersedia termasuk disk cepat dan disk lambat, yang cepat dapat dikelompokkan ke satu VG dan yang lambat ke lain; potongan pertama dapat kemudian ditugaskan untuk aplikasi yang membutuhkan akses data yang cepat, sementara yang kedua akan disimpan untuk tugas-tugas yang kurang menuntut.

en: In any case, keep in mind that an LV isn't particularly attached to any one PV. It is possible to influence where the data from an LV are physically stored, but this possibility isn't required for day-to-day use. On the contrary: when the set of physical components of a VG evolves, the physical storage locations corresponding to a particular LV can be migrated across disks (while staying within the PVs assigned to the VG, of course).
id-ID: Dalam kasus apapun, perlu diingat bahwa LV tidak perlu melekat ke PV manapun. Dimungkinkan untuk mempengaruhi mana data dari LV secara fisik disimpan, tapi kemungkinan ini tidak diperlukan untuk penggunaan sehari-hari. Sebaliknya: ketika set komponen fisik VG berkembang, lokasi penyimpanan fisik yang sesuai dengan LV tertentu dapat bermigrasi di seluruh disk (dan tentu saja tetap di dalam PVs yang ditugaskan untuk VG).

en: Setting up LVM
id-ID: Menyiapkan LVM

en: Let us now follow, step by step, the process of setting up LVM for a typical use case: we want to simplify a complex storage situation. Such a situation usually happens after some long and convoluted history of accumulated temporary measures. For the purposes of illustration, we'll consider a server where the storage needs have changed over time, ending up in a maze of available partitions split over several partially used disks. In more concrete terms, the following partitions are available:
id-ID: Mari kita sekarang ikuti, langkah demi langkah, proses pengaturan LVM untuk kasus penggunaan yang khas: kami ingin menyederhanakan situasi kompleks penyimpanan. Situasi seperti ini biasanya terjadi setelah beberapa sejarah yang panjang dan berbelit dari akumulasi langkah-langkah sementara. Untuk tujuan ilustrasi, kami akan mempertimbangkan server yang kebutuhan penyimpanannya telah berubah dari waktu ke waktu, berakhir dalam labirin dari partisi-partisi yang terpecah ke beberapa disk yang terpakai sebagian. Secara lebih konkret, partisi berikut tersedia:

en: on the <filename>sdb</filename> disk, a <filename>sdb2</filename> partition, 4 GB;
id-ID: pada disk <filename>sdb</filename>, sebuah partisi <filename>sdb2</filename>, 4 GB;

en: on the <filename>sdc</filename> disk, a <filename>sdc3</filename> partition, 3 GB;
id-ID: pada disk <filename>sdc</filename>, sebuah partisi <filename>sdc3</filename>, 3 GB;

en: the <filename>sdd</filename> disk, 4 GB, is fully available;
id-ID: disk <filename>sdd</filename>, 4 GB, sepenuhnya tersedia;

en: on the <filename>sdf</filename> disk, a <filename>sdf1</filename> partition, 4 GB; and a <filename>sdf2</filename> partition, 5 GB.
id-ID: pada disk <filename>sdf</filename>, partisi <filename>sdf1</filename>, 4 GB; dan partisi <filename>sdf2</filename>, 5 GB.

en: In addition, let's assume that disks <filename>sdb</filename> and <filename>sdf</filename> are faster than the other two.
id-ID: Selain itu, mari kita asumsikan bahwa disk <filename>sdb</filename> dan <filename>sdf</filename> adalah lebih cepat daripada dua lainnya.

en: Our goal is to set up three logical volumes for three different applications: a file server requiring 5 GB of storage space, a database (1 GB) and some space for back-ups (12 GB). The first two need good performance, but back-ups are less critical in terms of access speed. All these constraints prevent the use of partitions on their own; using LVM can abstract the physical size of the devices, so the only limit is the total available space.
id-ID: Tujuan kami adalah untuk mengatur tiga volume logis untuk tiga aplikasi yang berbeda: server berkas memerlukan ruang penyimpanan 5 GB, sebuah basis data (1 GB) dan ruang untuk back-up (12 GB). Dua yang pertama perlu kinerja yang baik, tapi back-up kurang kritis dalam hal kecepatan akses. Semua kendala ini mencegah penggunaan partisi sendirian; menggunakan LVM dapat mengabstraksi ukuran fisik dari perangkat, sehingga satu-satunya batas adalah jumlah ruang yang tersedia.

en: The required tools are in the <emphasis role="pkg">lvm2</emphasis> package and its dependencies. When they're installed, setting up LVM takes three steps, matching the three levels of concepts.
id-ID: Alat-alat yang diperlukan ada dalam paket <emphasis role="pkg">lvm2</emphasis> dan dependensinya. Ketika mereka sedang diinstal, pengaturan LVM mengambil tiga langkah, cocok dengan konsep tiga tingkat.

en: First, we prepare the physical volumes using <command>pvcreate</command>:
id-ID: Pertama, kami siapkan volume fisik menggunakan <command>pvcreate</command>:

en: So far, so good; note that a PV can be set up on a full disk as well as on individual partitions of it. As shown above, the <command>pvdisplay</command> command lists the existing PVs, with two possible output formats.
id-ID: Sejauh ini, masih baik; perhatikan bahwa PV dapat disiapkan pada seluruh disk maupun pada partisi individunya. Seperti yang ditunjukkan di atas, perintah <command>pvdisplay</command> menampilkan daftar PVs yang ada, dengan dua format keluaran mungkin.

en: Now let's assemble these physical elements into VGs using <command>vgcreate</command>. We'll gather only PVs from the fast disks into a <filename>vg_critical</filename> VG; the other VG, <filename>vg_normal</filename>, will also include slower elements.
id-ID: Sekarang mari kita merakit elemen-elemen fisik ini menjadi VG menggunakan <command>vgcreate</command>. Kita akan mengumpulkan hanya PV-PV dari disk cepat ke VG <filename>vg_critical</filename>; VG lain, <filename>vg_normal</filename>, juga akan memuat elemen-elemen yang lebih lambat.

en: Here again, commands are rather straightforward (and <command>vgdisplay</command> proposes two output formats). Note that it is quite possible to use two partitions of the same physical disk into two different VGs. Note also that we used a <filename>vg_</filename> prefix to name our VGs, but it is nothing more than a convention.
id-ID: Di sini lagi, perintahnya agak sederhana (dan <command>vgdisplay</command> mengusulkan dua format output). Perhatikan bahwa sangat mungkin untuk menggunakan dua partisi dari disk fisik yang sama ke dua VG yang berbeda. Perhatikan juga bahwa kita menggunakan awalan <filename>vg_</filename> untuk nama VG kita, tapi itu tidak lebih dari sebuah konvensi.

en: We now have two “virtual disks”, sized about 8 GB and 12 GB respectively. Let's now carve them up into “virtual partitions” (LVs). This involves the <command>lvcreate</command> command, and a slightly more complex syntax:
id-ID: Kita sekarang memiliki dua "disk virtual", masing-masing berukuran sekitar 8 GB dan 12 GB. Mari kita sekarang mengukir mereka ke dalam "partisi virtual" (LV). Ini melibatkan perintah <command>lvcreate</command>, dan sintaks yang agak lebih kompleks:

en: Two parameters are required when creating logical volumes; they must be passed to the <command>lvcreate</command> as options. The name of the LV to be created is specified with the <literal>-n</literal> option, and its size is generally given using the <literal>-L</literal> option. We also need to tell the command what VG to operate on, of course, hence the last parameter on the command line.
id-ID: Dua parameter diperlukan ketika membuat volume logis; mereka harus diberikan ke <command>lvcreate</command> sebagai opsi. Nama LV yang akan dibuat ditetapkan dengan opsi <literal>-n</literal>, dan ukurannya biasanya diberikan menggunakan opsi <literal>-L</literal>. Tentu saja kita juga perlu memberitahu ke perintah, VG mana yang dikenai operasi, maka diberikanlah parameter terakhir pada baris perintah.

en: <emphasis>GOING FURTHER</emphasis> <command>lvcreate</command> options
id-ID: <emphasis>LEBIH JAUH</emphasis> opsi-opsi <command>lvcreate</command>

en: The <command>lvcreate</command> command has several options to allow tweaking how the LV is created.
id-ID: Perintah <command>lvcreate</command> memiliki beberapa opsi untuk memungkinkan menala atas bagaimana cara LV dibuat.

en: Let's first describe the <literal>-l</literal> option, with which the LV's size can be given as a number of blocks (as opposed to the “human” units we used above). These blocks (called PEs, <emphasis>physical extents</emphasis>, in LVM terms) are contiguous units of storage space in PVs, and they can't be split across LVs. When one wants to define storage space for an LV with some precision, for instance to use the full available space, the <literal>-l</literal> option will probably be preferred over <literal>-L</literal>.
id-ID: Mari kita pertama menjelaskan opsi <literal>-l</literal>, dengannya ukuran LV dapat diberikan sebagai cacah blok (sebagai lawan dari unit "manusia" yang kita digunakan di atas). Blok-blok ini (disebut PE, <emphasis>physical extents</emphasis> dalam istilah LVM) adalah unit-unit ruang penyimpanan yang bersebelahan di PV, dan mereka tidak dapat dipecah di LV. Ketika seseorang ingin menentukan ruang penyimpanan untuk LV secara cukup presisi, misalnya menggunakan seluruh ruang yang tersedia, opsi <literal>-l</literal> mungkin akan lebih disukai daripada <literal>-L</literal>.

en: It is also possible to hint at the physical location of an LV, so that its extents are stored on a particular PV (while staying within the ones assigned to the VG, of course). Since we know that <filename>sdb</filename> is faster than <filename>sdf</filename>, we may want to store the <filename>lv_base</filename> there if we want to give an advantage to the database server compared to the file server. The command line becomes: <command>lvcreate -n lv_base -L 1G vg_critical /dev/sdb2</command>. Note that this command can fail if the PV doesn't have enough free extents. In our example, we would probably have to create <filename>lv_base</filename> before <filename>lv_files</filename> to avoid this situation – or free up some space on <filename>sdb2</filename> with the <command>pvmove</command> command.
id-ID: Memungkinkan juga untuk menunjuk pada lokasi fisik LV, sehingga extent disimpan pada PV tertentu (tentu saja masih tetap ada di dalam yang ditugaskan untuk VG). Karena kita tahu bahwa <filename>sdb</filename> lebih cepat daripada <filename>sdf</filename>, kita mungkin ingin menyimpan <filename>lv_base</filename> di sana jika kita ingin memberikan keuntungan kepada server basis data dibandingkan dengan server berkas. Baris perintah menjadi: <command>lvcreate -n lv_base -L 1G vg_critical /dev/sdb2</command>. Perhatikan bahwa perintah ini bisa gagal jika PV tidak memiliki cukup extent bebas. Dalam contoh kita, kita mungkin harus membuat <filename>lv_base</filename> sebelum <filename>lv_files</filename> untuk menghindari situasi ini - atau membebaskan sebagian ruang di <filename>sdb2</filename> dengan perintah <command>pvmove</command>.

en: Logical volumes, once created, end up as block device files in <filename>/dev/mapper/</filename>:
id-ID: Volume logis, sekali dibuat, akan menjadi berkas perangkat blok dalam <filename>/dev/mapper/</filename>:

en: <emphasis>NOTE</emphasis> Auto-detecting LVM volumes
id-ID: <emphasis>CATATAN</emphasis> Mendeteksi otomatis volume LVM

en: When the computer boots, the <filename>lvm2-activation</filename> systemd service unit executes <command>vgchange -aay</command> to “activate” the volume groups: it scans the available devices; those that have been initialized as physical volumes for LVM are registered into the LVM subsystem, those that belong to volume groups are assembled, and the relevant logical volumes are started and made available. There is therefore no need to edit configuration files when creating or modifying LVM volumes.
id-ID: Ketika komputer boot, unit layanan systemd <filename>lvm2-activation</filename> mengeksekusi <command>vgchange -aay</command> untuk "mengaktifkan" kelompok volume: memindai perangkat yang tersedia; yang telah diinisialisasi sebagai fisik untuk LVM didaftarkan ke subsistem LVM, yang berasal dari kelompok-kelompok volume dirakit, dan volume logis yang relevan dimulai dan dibuat tersedia. Karena itu tidak perlu menyunting berkas konfigurasi ketika membuat atau memodifikasi volume-volume LVM.

en: Note, however, that the layout of the LVM elements (physical and logical volumes, and volume groups) is backed up in <filename>/etc/lvm/backup</filename>, which can be useful in case of a problem (or just to sneak a peek under the hood).
id-ID: Namun, perlu diketahui bahwa tata letak elemen LVM (volume fisik dan logis, dan kelompok-kelompok volume) direkam cadang dalam <filename>/etc/lvm/backup</filename>, yang dapat berguna dalam hal ada masalah (atau hanya untuk sekedar mengintip di balik layar).

en: To make things easier, convenience symbolic links are also created in directories matching the VGs:
id-ID: Untuk membuat semua lebih mudah, taut simbolik juga dibuat dalam direktori-direktori yang cocok dengan VG:

en: The LVs can then be used exactly like standard partitions:
id-ID: LV kemudian dapat digunakan persis seperti partisi standar:

en: From the applications' point of view, the myriad small partitions have now been abstracted into one large 12 GB volume, with a friendlier name.
id-ID: Dari sudut pandang aplikasi, berbagai partisi kecil sekarang telah diabstrakkan ke dalam satu volume 12 GB besar, dengan nama yang lebih mudah.

en: LVM Over Time
id-ID: LVM Dari Waktu Ke Waktu

en: Even though the ability to aggregate partitions or physical disks is convenient, this is not the main advantage brought by LVM. The flexibility it brings is especially noticed as time passes, when needs evolve. In our example, let's assume that new large files must be stored, and that the LV dedicated to the file server is too small to contain them. Since we haven't used the whole space available in <filename>vg_critical</filename>, we can grow <filename>lv_files</filename>. For that purpose, we'll use the <command>lvresize</command> command, then <command>resize2fs</command> to adapt the filesystem accordingly:
id-ID: Meskipun kemampuan untuk mengagregasi partisi atau disk fisik itu nyaman, ini bukanlah keuntungan utama yang dibawa oleh LVM. Fleksibilitas yang dibawanya terutama teramati seiring berjalannya waktu, ketika kebutuhan berevolusi. Dalam contoh kita, mari kita asumsikan bahwa berkas besar baru harus disimpan, dan bahwa LV yang didedikasikan untuk server berkas terlalu kecil untuk menampung mereka. Karena kita belum menggunakan seluruh ruang yang tersedia di <filename>vg_critical</filename>, kita bisa perbesar <filename>lv_files</filename>. Untuk tujuan tersebut, kita akan menggunakan perintah <command>lvresize</command>, lalu <command>resize2fs</command> untuk mengadaptasi sistem berkas:

en: <emphasis>CAUTION</emphasis> Resizing filesystems
id-ID: <emphasis>HATI-HATI</emphasis> Mengubah ukuran sistem berkas

en: Not all filesystems can be resized online; resizing a volume can therefore require unmounting the filesystem first and remounting it afterwards. Of course, if one wants to shrink the space allocated to an LV, the filesystem must be shrunk first; the order is reversed when the resizing goes in the other direction: the logical volume must be grown before the filesystem on it. It is rather straightforward, since at no time must the filesystem size be larger than the block device where it resides (whether that device is a physical partition or a logical volume).
id-ID: Tidak semua sistem berkas dapat diubah ukurannya secara daring; mengubah ukuran volume oleh karena itu mungkin pertama memerlukan melepas kait sistem berkas dan mengait ulang setelah itu. Tentu saja, jika seseorang ingin mengecilkan ruang yang dialokasikan untuk LV, sistem berkas harus diperkecil dulu; urutan dibalik ketika perubahan ukuran untuk arah lain: volume logis harus diperbesar sebelum sistem berkas di atasnya. Hal ini cukup sederhana, karena kapanpun ukuran sistem tidak boleh lebih besar dari perangkat blok tempat dia berada (apakah perangkat berupa partisi fisik atau volume logis).

en: The ext3, ext4 and xfs filesystems can be grown online, without unmounting; shrinking requires an unmount. The reiserfs filesystem allows online resizing in both directions. The venerable ext2 allows neither, and always requires unmounting.
id-ID: Sistem berkas ext3, ext4, dan xfs dapat diperbesar secara daring, tanpa melepas kain; menyusutkan memerlukan melepas kait. Sistem berkas reiserfs memungkinkan perubahan ukuran secara daring di kedua arah. ext2 tidak memungkinkan keduanya, dan selalu membutuhkan melepas kait.

en: We could proceed in a similar fashion to extend the volume hosting the database, only we've reached the VG's available space limit:
id-ID: Kita bisa melanjutkan dengan cara yang sama untuk memperbesar volume yang mewadai basis data, tapi kita telah mencapai batas ruang VG yang tersedia:

en: <emphasis>GOING FURTHER</emphasis> Advanced LVM
id-ID: <emphasis>LEBIH JAUH</emphasis> LVM tingkat lanjut

en: LVM also caters for more advanced uses, where many details can be specified by hand. For instance, an administrator can tweak the size of the blocks that make up physical and logical volumes, as well as their physical layout. It is also possible to move blocks across PVs, for instance, to fine-tune performance or, in a more mundane way, to free a PV when one needs to extract the corresponding physical disk from the VG (whether to affect it to another VG or to remove it from LVM altogether). The manual pages describing the commands are generally clear and detailed. A good entry point is the <citerefentry><refentrytitle>lvm</refentrytitle> <manvolnum>8</manvolnum></citerefentry> manual page.
id-ID: LVM juga melayani untuk penggunaan tingkat lanjut, dimana banyak rincian dapat dinyatakan secara manual. Misalnya, administrator dapat menala ukuran blok yang membuat volume fisik dan logis, serta letak fisik mereka. Juga mungkin untuk memindahkan blok di PV, misalnya untuk menala halus kinerja atau, dalam cara yang lebih biasa, untuk membebaskan PV ketika kita perlu mengekstrak disk fisik yang sesuai dari VG (baik untuk mempengaruhi bagi VG lain atau menghapusnya dari LVM sama sekali). Halaman manual yang menguraikan perintah umumnya jelas dan rinci. Titik awal yang baik adalah halaman manual <citerefentry><refentrytitle>lvm</refentrytitle> <manvolnum>8</manvolnum></citerefentry>.

en: RAID or LVM?
id-ID: RAID atau LVM?

en: RAID and LVM both bring indisputable advantages as soon as one leaves the simple case of a desktop computer with a single hard disk where the usage pattern doesn't change over time. However, RAID and LVM go in two different directions, with diverging goals, and it is legitimate to wonder which one should be adopted. The most appropriate answer will of course depend on current and foreseeable requirements.
id-ID: RAID dan LVM keduanya membawa keuntungan tak terbantahkan bila kita abaikan kasus sederhana komputer desktop dengan satu hard disk dengan pola penggunaan tidak berubah dari waktu ke waktu. Namun, RAID dan LVM mengambil arah yang berbeda, dengan tujuan divergen, dan sah-sah saja bertanya-tanya mana yang harus diambil. Jawaban paling tepat akan tentu saja tergantung pada kebutuhan saat ini dan masa mendatang.

en: There are a few simple cases where the question doesn't really arise. If the requirement is to safeguard data against hardware failures, then obviously RAID will be set up on a redundant array of disks, since LVM doesn't really address this problem. If, on the other hand, the need is for a flexible storage scheme where the volumes are made independent of the physical layout of the disks, RAID doesn't help much and LVM will be the natural choice.
id-ID: Ada beberapa kasus sederhana dimana pertanyaan tidak benar-benar muncul. Jika kebutuhan adalah untuk mengamankan data terhadap kegagalan perangkat keras, maka jelas RAID akan disiapkan pada array disk, karena LVM tidak benar-benar menjawab masalah ini. Si sisi lain, jika kebutuhan adalah untuk skema penyimpanan yang fleksibel dimana volume dibuat independen terhadap tata letak fisik dari disk, RAID tidak banyak membantu dan LVM akan menjadi pilihan yang tepat.

en: <emphasis>NOTE</emphasis> If performance matters…
id-ID: <emphasis>CATATAN</emphasis> Jika kinerja penting…

en: The third notable use case is when one just wants to aggregate two disks into one volume, either for performance reasons or to have a single filesystem that is larger than any of the available disks. This case can be addressed both by a RAID-0 (or even linear-RAID) and by an LVM volume. When in this situation, and barring extra constraints (for instance, keeping in line with the rest of the computers if they only use RAID), the configuration of choice will often be LVM. The initial set up is barely more complex, and that slight increase in complexity more than makes up for the extra flexibility that LVM brings if the requirements change or if new disks need to be added.
id-ID: Use case ketiga yang menarik adalah ketika seseorang hanya ingin mengagregat dua disk ke dalam satu volume, baik untuk alasan kinerja atau memiliki sistem berkas tunggal yang lebih besar daripada salah satu disk yang tersedia. Hal ini dapat dijawab oleh RAID 0 (atau bahkan linear-RAID) maupun dengan volume LVM. Dalam situasi ini, dan tanpa batasan tambahan kendala (misalnya, menjaga sejalan dengan sisa komputer jika mereka hanya menggunakan RAID), konfigurasi pilihan akan seringkali adalah LVM. Penyiapan awal hampir tidak lebih kompleks, dan bahwa sedikit peningkatan kompleksitas terbayar oleh fleksibilitas tambahan yang dibawah oleh LVM jika persyaratan berubah atau jika disk baru perlu ditambahkan.

en: Then of course, there is the really interesting use case, where the storage system needs to be made both resistant to hardware failure and flexible when it comes to volume allocation. Neither RAID nor LVM can address both requirements on their own; no matter, this is where we use both at the same time — or rather, one on top of the other. The scheme that has all but become a standard since RAID and LVM have reached maturity is to ensure data redundancy first by grouping disks in a small number of large RAID arrays, and to use these RAID arrays as LVM physical volumes; logical partitions will then be carved from these LVs for filesystems. The selling point of this setup is that when a disk fails, only a small number of RAID arrays will need to be reconstructed, thereby limiting the time spent by the administrator for recovery.
id-ID: Kemudian tentu saja, ada kasus penggunaan yang benar-benar menarik, dimana sistem penyimpanan perlu dibuat tahan terhadap kegagalan perangkat keras dan fleksibel tentang alokasi volume. RAID maupun LVM masing-masing dapat menjawab kedua persyaratan; ini adalah di mana kita menggunakan keduanya pada saat yang sama -- atau lebih tepatnya, satu di atas yang lain. Skema yang memiliki semua tapi belum menjadi standar karena RAID dan LVM telah mencapai kedewasaan untuk memastikan redundansi data pertama dengan pengelompokan disk dalam sejumlah kecil larik RAID besar, dan menggunakan larik RAID ini sebagai volume fisik LVM; partisi logis kemudian dapat ditoreh dari LV-LV ini untuk sistem berkas. Nilai jual konfigurasi ini adalah bahwa ketika sebuah disk gagal, hanya sejumlah kecil larik RAID yang perlu dibangun kembali, sehingga membatasi waktu yang dihabiskan oleh administrator untuk pemulihan.

en: RAID-1 and LVM are combined to satisfy these constraints. The disks are attached to two different SATA controllers to optimize parallel access and reduce the risk of a simultaneous failure, and they therefore appear as <filename>sda</filename> and <filename>sdc</filename>. They are partitioned identically along the following scheme:
id-ID: RAID-1 dan LVM digabungkan untuk memenuhi batasan-batasan ini. Disk dilekatkan pada dua pengendali SATA yang berbeda untuk mengoptimalkan akses paralel dan mengurangi risiko kegagalan simultan, dan karena itu mereka muncul sebagai <filename>sda</filename> dan <filename>sdc</filename>. Mereka dipartisi secara identik mengikut skema sebagai berikut:

en: Once the VGs are created, they can be partitioned in a very flexible way. One must keep in mind that LVs created in <filename>vg_raid</filename> will be preserved even if one of the disks fails, which will not be the case for LVs created in <filename>vg_bulk</filename>; on the other hand, the latter will be allocated in parallel on both disks, which allows higher read or write speeds for large files.
id-ID: Setelah VGs dibuat, mereka dapat dipartisi dengan cara yang sangat fleksibel. Harus tetap diingat bahwa LV yang dibuat dalam <filename>vg_raid</filename> akan dipertahankan bahkan jika salah satu disk gagal, yang tidak akan terjadi untuk LV dibuat di <filename>vg_bulk</filename>; di sisi lain, yang kedua akan dialokasikan secara paralel pada kedua disk, yang memungkinkan kecepatan baca atau tulis yang lebih tinggi untuk berkas-berkas besar.

en: We will therefore create the <filename>lv_var</filename> and <filename>lv_home</filename> LVs on <filename>vg_raid</filename>, to host the matching filesystems; another large LV, <filename>lv_movies</filename>, will be used to host the definitive versions of movies after editing. The other VG will be split into a large <filename>lv_rushes</filename>, for data straight out of the digital video cameras, and a <filename>lv_tmp</filename> for temporary files. The location of the work area is a less straightforward choice to make: while good performance is needed for that volume, is it worth risking losing work if a disk fails during an editing session? Depending on the answer to that question, the relevant LV will be created on one VG or the other.
id-ID: Karena itu kita akan membuat LV <filename>lv_var</filename>, dan <filename>lv_home</filename> pada <filename>vg_raid</filename>, untuk mewadahi sistem berkas yang cocok; LV besar lain, <filename>lv_movies</filename>, akan digunakan untuk mewadahi film-film versi definitif setelah penyuntingan. VG lain akan dibagi menjadi <filename>lv_rushes</filename>yang besar, untuk data langsung dari kamera video digital, dan <filename>lv_tmp</filename> untuk berkas-berkas sementara. Lokasi area kerja adalah pilihan yang kurang mudah untuk dibuat: sementara kinerja yang baik diperlukan untuk volume itu, apakah layak risiko kehilangan pekerjaan jika disk gagal selama sesi menyunting? Tergantung pada jawaban untuk pertanyaan itu, LV yang relevan akan dibuat pada satu VG atau yang lain.

en: We now have both some redundancy for important data and much flexibility in how the available space is split across the applications.
id-ID: Kita sekarang memiliki sebagian redundansi untuk data penting dan banyak fleksibilitas dalam bagaimana ruang yang tersedia dibagi atas berbagai aplikasi.

en: <emphasis>NOTE</emphasis> Why three RAID-1 volumes?
id-ID: <emphasis>CATATAN</emphasis> Mengapa tiga volume RAID-1?

en: We could have set up one RAID-1 volume only, to serve as a physical volume for <filename>vg_raid</filename>. Why create three of them, then?
id-ID: Kita bisa saja menyiapkan hanya satu volume RAID-1, untuk melayani sebagai volume fisik bagi <filename>vg_raid</filename>. Lalu mengapa membuat tiga?

en: The rationale for the first split (<filename>md0</filename> vs. the others) is about data safety: data written to both elements of a RAID-1 mirror are exactly the same, and it is therefore possible to bypass the RAID layer and mount one of the disks directly. In case of a kernel bug, for instance, or if the LVM metadata become corrupted, it is still possible to boot a minimal system to access critical data such as the layout of disks in the RAID and LVM volumes; the metadata can then be reconstructed and the files can be accessed again, so that the system can be brought back to its nominal state.
id-ID: Alasan untuk pemecahan pertama (<filename>md0</filename> vs yang lain) adalah tentang keamanan data: data yang ditulis ke kedua elemen dari cermin RAID 1 persis sama, dan karena itu mungkin untuk melewati lapisan RAID dan mengait salah satu disk secara langsung. Dalam kasus bug kernel, misalnya, atau jika metadata LVM menjadi rusak, itu masih mungkin untuk mem-boot sistem minimal untuk mengakses data penting seperti tata letak disk dalam RAID dan volume LVM; metadata dapat kemudian direkonstruksi dan berkas dapat diakses lagi, sehingga sistem dapat dibawa kembali ke keadaan nominal.

en: <primary>virtualization</primary>
id-ID: <primary>virtualisasi</primary>

en: Virtualization is one of the most major advances in the recent years of computing. The term covers various abstractions and techniques simulating virtual computers with a variable degree of independence on the actual hardware. One physical server can then host several systems working at the same time and in isolation. Applications are many, and often derive from this isolation: test environments with varying configurations for instance, or separation of hosted services across different virtual machines for security.
id-ID: Virtualisasi adalah salah satu kemajuan yang paling besar dalam beberapa tahun terakhir komputasi. Istilah ini mencakup berbagai abstraksi dan teknik simulasi komputer virtual dengan tingkat kebebasan yang variabel pada perangkat keras sebenarnya. Satu server fisik kemudian dapat mewadahi beberapa sistem yang bekerja pada waktu yang sama dan dalam isolasi. Ada banyak aplikasi, dan sering diturunkan dari isolasi ini: lingkungan uji dengan berbagai konfigurasi misalnya, atau pemisahan layanan kebeberapa mesin virtual untuk keamanan.

en: There are multiple virtualization solutions, each with its own pros and cons. This book will focus on Xen, LXC, and KVM, but other noteworthy implementations include the following:
id-ID: Ada beberapa solusi virtualisasi, masing-masing dengan pro dan kontra. Buku ini akan fokus pada Xen, LXC, dan KVM, tetapi implementasi penting lain adalah sebagai berikut:

en: Bochs is another free virtual machine, but it only emulates the x86 architectures (i386 and amd64).
id-ID: Bochs adalah mesin virtual lain yang bebas, tapi itu hanya mengemulasi arsitektur x86 (i386 dan amd64).

en: <emphasis>HARDWARE</emphasis> Virtualization support
id-ID: <emphasis>PERANGKAT KERAS</emphasis> Dukungan virtualisasi

en: Some computers might not have hardware virtualization support; when they do, it should be enabled in the BIOS.
id-ID: Beberapa komputer mungkin tidak memiliki dukungan virtualisasi perangkat keras; ketika ada, itu harus diaktifkan di BIOS.

en: To know if you have virtualization support enabled, you can check if the relevant flag is enabled with <command>grep</command>. If the following command for your processor returns some text, you already have virtualization support enabled:
id-ID: Untuk mengetahui apakah dukungan virtualisasi Anda diaktifkan, Anda dapat memeriksa apakah flag yang relevan diaktifkan dengan <command>grep</command>. Jika perintah berikut untuk prosesor Anda mengembalikan teks, dukungan virtualisasi Anda sudah diaktifkan:

en: Xen <indexterm><primary>Xen</primary></indexterm> is a “paravirtualization” solution. It introduces a thin abstraction layer, called a “hypervisor”, between the hardware and the upper systems; this acts as a referee that controls access to hardware from the virtual machines. However, it only handles a few of the instructions, the rest is directly executed by the hardware on behalf of the systems. The main advantage is that performances are not degraded, and systems run close to native speed; the drawback is that the kernels of the operating systems one wishes to use on a Xen hypervisor need to be adapted to run on Xen.
id-ID: Xen <indexterm><primary>Xen</primary></indexterm> adalah sebuah solusi "paravirtualization". Ini memperkenalkan lapisan abstraksi tipis, dinamai "hypervisor", antara perangkat keras dan sistem di atas; ini bekerja sebagai wasit yang mengendalikan akses ke perangkat keras dari mesin-mesin virtual. Namun, itu hanya menangani beberapa instruksi, sisanya dieksekusi secara langsung oleh perangkat keras atas nama sistem. Keuntungan utama adalah kinerja tidak menurun, dan sistem berjalan mendekati kecepatan native; kekurangannya adalah kernal dari sistem operasi yang ingin dipakai pada suatu hypervisor Xen perlu diadaptasi untuk berjalan pada Xen.

en: Let's spend some time on terms. The hypervisor is the lowest layer, which runs directly on the hardware, even below the kernel. This hypervisor can split the rest of the software across several <emphasis>domains</emphasis>, which can be seen as so many virtual machines. One of these domains (the first one that gets started) is known as <emphasis>dom0</emphasis>, and has a special role, since only this domain can control the hypervisor and the execution of other domains. These other domains are known as <emphasis>domU</emphasis>. In other words, and from a user point of view, the <emphasis>dom0</emphasis> matches the “host” of other virtualization systems, while a <emphasis>domU</emphasis> can be seen as a “guest”.
id-ID: Mari kita bahas sejenak istilah-istilah. Hypervisor adalah lapisan terendah, yang berjalan langsung pada perangkat keras, bahkan di bawah kernel. Hypervisor ini dapat membagi sisa perangkat lunak di beberapa <emphasis>domain</emphasis>, yang dapat dilihat sebagai banyak mesin virtual. Salah satu domain (yang pertama dimulai) dikenal sebagai <emphasis>dom0</emphasis>, dan memiliki peran khusus, karena hanya domain ini dapat mengontrol hypervisor dan eksekusi domain lainnya. Domain lain tersebut dikenal sebagai <emphasis>domU</emphasis>. Dengan kata lain, dan dari sudut pandang pengguna, <emphasis>dom0</emphasis> adalah "host" sistem virtualisasi lain, sementara <emphasis>domU</emphasis> dapat dilihat sebagai "tamu".

en: <emphasis>CULTURE</emphasis> Xen and the various versions of Linux
id-ID: <emphasis>KULTUR</emphasis> Xen dan berbagai versi Linux

en: Xen was initially developed as a set of patches that lived out of the official tree, and not integrated to the Linux kernel. At the same time, several upcoming virtualization systems (including KVM) required some generic virtualization-related functions to facilitate their integration, and the Linux kernel gained this set of functions (known as the <emphasis>paravirt_ops</emphasis> or <emphasis>pv_ops</emphasis> interface). Since the Xen patches were duplicating some of the functionality of this interface, they couldn't be accepted officially.
id-ID: Xen ini awalnya dikembangkan sebagai seperangkat patch yang berada di luar pohon resmi, dan tidak terintegrasi ke kernel Linux. Pada saat yang sama, beberapa sistem virtualisasi mendatang (termasuk KVM) memerlukan beberapa fungsi generik terkait virtualisasi untuk memfasilitasi integrasi mereka, dan kernel Linux memperoleh set fungsi (dikenal sebagai antarmuka <emphasis>paravirt_ops </emphasis> atau <emphasis>pv_ops</emphasis>). Karena patch Xen menduplikasi beberapa fungsionalitas antar muka ini, mereka tidak bisa diterima secara resmi.

en: Xensource, the company behind Xen, therefore had to port Xen to this new framework, so that the Xen patches could be merged into the official Linux kernel. That meant a lot of code rewrite, and although Xensource soon had a working version based on the paravirt_ops interface, the patches were only progressively merged into the official kernel. The merge was completed in Linux 3.0. <ulink type="block" url="https://wiki.xenproject.org/wiki/XenParavirtOps" />
id-ID: XenSource, perusahaan di belakang Xen, karena itu harus mem-port Xen ke kerangka baru ini, sehingga patch Xen bisa digabungkan ke kernel Linux resmi. Itu berarti banyak penulisan ulang kode, dan meskipun Xensource segera memiliki versi yang bekerja berdasarkan antarmuka paravirt_ops, patch hanya digabungkan ke dalam kernel resmi secara progresif. Penggabungan selesai pada Linux 3.0. <ulink type="block" url="https://wiki.xenproject.org/wiki/XenParavirtOps" />

en: Since <emphasis role="distribution">Jessie</emphasis> is based on version 3.16 of the Linux kernel, the standard <emphasis role="pkg">linux-image-686-pae</emphasis> and <emphasis role="pkg">linux-image-amd64</emphasis> packages include the necessary code, and the distribution-specific patching that was required for <emphasis role="distribution">Squeeze</emphasis> and earlier versions of Debian is no more. <ulink type="block" url="https://wiki.xenproject.org/wiki/Xen_Kernel_Feature_Matrix" />
id-ID: Karena <emphasis role="distribution">Jessie</emphasis> didasarkan pada kernel Linux versi 3.16, paket-paket standar <emphasis role="pkg">linux-image-686-pae</emphasis> dan <emphasis role="pkg">linux-image-amd64</emphasis> menyertakan kode yang diperlukan, dan patch spesifik distribusi yang diperlukan untuk <emphasis role="distribution">Squeeze</emphasis> dan versi sebelumnya dari Debian tidak diperlukan lagi. <ulink type="block" url="https://wiki.xenproject.org/wiki/Xen_Kernel_Feature_Matrix" />

en: <emphasis>CULTURE</emphasis> Xen and non-Linux kernels
id-ID: <emphasis>BUDAYA</emphasis> Xen dan kernel bukan Linux

en: Xen requires modifications to all the operating systems one wants to run on it; not all kernels have the same level of maturity in this regard. Many are fully-functional, both as dom0 and domU: Linux 3.0 and later, NetBSD 4.0 and later, and OpenSolaris. Others only work as a domU. You can check the status of each operating system in the Xen wiki: <ulink type="block" url="https://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen" /> <ulink type="block" url="https://wiki.xenproject.org/wiki/DomU_Support_for_Xen" />
id-ID: Xen memerlukan modifikasi ke semua sistem operasi yang ingin berjalan di atasnya; tidak semua kernel memiliki tingkat kedewasaan yang sama dalam hal ini. Banyak yang fungsional-penuh, baik sebagai dom0 maupun domU: Linux 3.0 dan setelahnya, NetBSD 4.0 dan setelahnya, dan OpenSolaris. Yang lain hanya bekerja sebagai domU. Anda dapat memeriksa status dari setiap sistem operasi di wiki Xen: <ulink type="block" url="https://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen" /> <ulink type="block" url="https://wiki.xenproject.org/wiki/DomU_Support_for_Xen" />

en: However, if Xen can rely on the hardware functions dedicated to virtualization (which are only present in more recent processors), even non-modified operating systems can run as domU (including Windows).
id-ID: Namun, jika Xen dapat bergantung pada fungsi perangkat keras yang didedikasikan untuk virtualisasi (yang hanya hadir dalam prosesor yang lebih baru), bahkan sistem operasi tanpa modifikasi dapat berjalan sebagai domU (termasuk Windows).

en: <emphasis>NOTE</emphasis> Architectures compatible with Xen
id-ID: <emphasis>CATATAN</emphasis> Arsitektur yang kompatibel dengan Xen

en: Xen is currently only available for the i386, amd64, arm64 and armhf architectures.
id-ID: Xen saat ini hanya tersedia untuk arsitektur i386, amd64, arm64, dan armhf.

en: Using Xen under Debian requires three components:
id-ID: Menggunakan Xen di bawah Debian memerlukan tiga komponen:

en: The i386 architecture also requires a standard library with the appropriate patches taking advantage of Xen; this is in the <emphasis role="pkg">libc6-xen</emphasis> package.
id-ID: Arsitektur i386 juga memerlukan pustaka standar dengan patch yang sesuai yang mengambil keuntungan dari Xen; ini ada dalam paket <emphasis role="pkg">libc6-xen</emphasis>.

en: Once these prerequisites are installed, the next step is to test the behavior of the dom0 by itself; this involves a reboot to the hypervisor and the Xen kernel. The system should boot in its standard fashion, with a few extra messages on the console during the early initialization steps.
id-ID: Setelah prapersyaratan ini diinstal, langkah berikutnya adalah untuk menguji perilaku dom0 sendiri; ini melibatkan reboot hypervisor dan kernel Xen. Sistem harus boot dalam cara standar, dengan beberapa tambahan pesan pada konsol selama langkah inisialisasi awal.

en: Now is the time to actually install useful systems on the domU systems, using the tools from <emphasis role="pkg">xen-tools</emphasis>. This package provides the <command>xen-create-image</command> command, which largely automates the task. The only mandatory parameter is <literal>--hostname</literal>, giving a name to the domU; other options are important, but they can be stored in the <filename>/etc/xen-tools/xen-tools.conf</filename> configuration file, and their absence from the command line doesn't trigger an error. It is therefore important to either check the contents of this file before creating images, or to use extra parameters in the <command>xen-create-image</command> invocation. Important parameters of note include the following:
id-ID: Sekarang adalah waktu untuk benar-benar menginstal sistem yang berguna pada sistem domU, menggunakan alat-alat dari <emphasis role="pkg">xen-tools</emphasis>. Paket ini menyediakan perintah <command>xen-create-image</command>, yang mengotomatiskan sebagian besar tugas. Satu-satunya parameter wajib adalah <literal>--hostname</literal>, yang memberikan nama kepada domU; pilihan lainnya penting, tetapi mereka dapat disimpan dalam berkas konfigurasi <filename>/etc/xen-tools/xen-tools.conf</filename> dan ketidakhadiran mereka dari baris perintah tidak memicu kesalahan. Karena itu penting untuk memeriksa isi dari berkas ini sebelum membuat image, atau menggunakan parameter tambahan dalam pemanggilan <command>xen-create-image</command>. Parameter yang penting untuk diperhatikan adalah sebagai berikut:

en: <literal>--memory</literal>, to specify the amount of RAM dedicated to the newly created system;
id-ID: <literal>--memory</literal>, untuk menentukan banyaknya RAM yang didedikasikan bagi sistem yang baru dibuat;

en: <literal>--size</literal> and <literal>--swap</literal>, to define the size of the “virtual disks” available to the domU;
id-ID: <literal>--size</literal> dan <literal>--swap</literal>, untuk menentukan ukuran "disk virtual" yang tersedia bagi domU;

en: <emphasis>GOING FURTHER</emphasis> Installing a non-Debian system in a domU
id-ID: <emphasis>LEBIH JAUH</emphasis> Memasang sistem bukan-Debian di domU

en: In case of a non-Linux system, care should be taken to define the kernel the domU must use, using the <literal>--kernel</literal> option.
id-ID: Dalam hal non-Linux sistem, perlu hati-hati untuk mendefinisikan kernel yang mesti dipakai oleh domU, menggunakan opsi <literal>--kernel</literal>.

en: <literal>--dhcp</literal> states that the domU's network configuration should be obtained by DHCP while <literal>--ip</literal> allows defining a static IP address.
id-ID: <literal>--dhcp</literal> menyatakan bahwa konfigurasi jaringan domU harus diperoleh dengan DHCP sedangkan <literal>--ip</literal> memungkinkan menentukan alamat IP statis.

en: Lastly, a storage method must be chosen for the images to be created (those that will be seen as hard disk drives from the domU). The simplest method, corresponding to the <literal>--dir</literal> option, is to create one file on the dom0 for each device the domU should be provided. For systems using LVM, the alternative is to use the <literal>--lvm</literal> option, followed by the name of a volume group; <command>xen-create-image</command> will then create a new logical volume inside that group, and this logical volume will be made available to the domU as a hard disk drive.
id-ID: Terakhir, metode penyimpanan harus dipilih untuk image yang akan dibuat (yang akan dipandang sebagai hard disk drive dari domU). Metode paling sederhana, sesuai dengan pilihan <literal>--dir</literal>, adalah untuk menciptakan satu berkas pada dom0 untuk setiap perangkat yang harus disediakan oleh domU. Untuk sistem yang menggunakan LVM, alternatifnya adalah dengan menggunakan pilihan <literal>--lvm</literal>, diikuti oleh nama grup volume; <command>xen-create-image</command> kemudian akan menciptakan volume logis baru di dalam grup, dan volume logis ini akan dibuat tersedia bagi domU sebagai hard disk drive.

en: <emphasis>NOTE</emphasis> Storage in the domU
id-ID: <emphasis>CATATAN</emphasis> Penyimpanan di domU

en: Entire hard disks can also be exported to the domU, as well as partitions, RAID arrays or pre-existing LVM logical volumes. These operations are not automated by <command>xen-create-image</command>, however, so editing the Xen image's configuration file is in order after its initial creation with <command>xen-create-image</command>.
id-ID: Seluruh hard disk dapat juga diekspor ke domU, maupun partisi, larik RAID, atau volume logis LVM yang sudah ada sebelumnya. Namun operasi ini tidak diotomatiskan oleh <command>xen-create-image</command>, jadi perlu menyunting berkas konfigurasi image Xen setelah penciptaan awal dengan <command>xen-create-image</command>.

en: Once these choices are made, we can create the image for our future Xen domU:
id-ID: Setelah pilihan ini dibuat, kita dapat membuat image untuk domU Xen kita nanti:

en: We now have a virtual machine, but it is currently not running (and therefore only using space on the dom0's hard disk). Of course, we can create more images, possibly with different parameters.
id-ID: Kita sekarang memiliki mesin virtual, tetapi saat ini tidak berjalan (dan karena itu hanya menggunakan ruang hard disk dom0). Tentu saja, kita dapat membuat lebih banyak image, mungkin dengan parameter yang berbeda.

en: Before turning these virtual machines on, we need to define how they'll be accessed. They can of course be considered as isolated machines, only accessed through their system console, but this rarely matches the usage pattern. Most of the time, a domU will be considered as a remote server, and accessed only through a network. However, it would be quite inconvenient to add a network card for each domU; which is why Xen allows creating virtual interfaces that each domain can see and use in a standard way. Note that these cards, even though they're virtual, will only be useful once connected to a network, even a virtual one. Xen has several network models for that:
id-ID: Sebelum menyalakan mesin virtual ini, kita perlu menentukan bagaimana mereka akan diakses. Mereka tentu saja dapat dianggap mesin terisolasi, hanya diakses melalui konsol sistem mereka, tapi ini jarang cocok dengan pola penggunaan. Sebagian besar waktu, domU akan dianggap sebagai server jarak jauh, dan diakses hanya melalui jaringan. Namun, itu akan kurang nyaman untuk menambahkan kartu jaringan bagi setiap domU; itulah sebabnya Xen memungkinkan menciptakan antarmuka virtual, yang bisa dilihat dan digunakan dengan cara yang standar oleh setiap domain. Perhatikan bahwa kartu ini, meskipun mereka virtual, akan hanya menjadi berguna setelah terhubung ke jaringan, bahkan yang virtual. Xen memiliki beberapa model jaringan untuk itu:

en: The simplest model is the <emphasis>bridge</emphasis> model; all the eth0 network cards (both in the dom0 and the domU systems) behave as if they were directly plugged into an Ethernet switch.
id-ID: Model yang paling sederhana adalah model <emphasis>bridge</emphasis>; semua kartu jaringan eth0 (baik dalam dom0 dan sistem domU) bersikap seolah-olah mereka secara langsung terhubung ke switch Ethernet.

en: Then comes the <emphasis>routing</emphasis> model, where the dom0 behaves as a router that stands between the domU systems and the (physical) external network.
id-ID: Kemudian ada model <emphasis>routing</emphasis>, dimana dom0 berperilaku sebagai router yang berdiri di antara sistem domU dan jaringan eksternal (fisik).

en: Finally, in the <emphasis>NAT</emphasis> model, the dom0 is again between the domU systems and the rest of the network, but the domU systems are not directly accessible from outside, and traffic goes through some network address translation on the dom0.
id-ID: Akhirnya, dalam model <emphasis>NAT</emphasis>, dom0 lagi-lagi berada di antara sistem domU dan sisa jaringan, tetapi sistem domU tidak langsung dapat diakses dari luar, dan lalu lintas berjalan melalui perjemahan alamat jaringan pada dom0.

en: These three networking nodes involve a number of interfaces with unusual names, such as <filename>vif*</filename>, <filename>veth*</filename>, <filename>peth*</filename> and <filename>xenbr0</filename>. The Xen hypervisor arranges them in whichever layout has been defined, under the control of the user-space tools. Since the NAT and routing models are only adapted to particular cases, we will only address the bridging model.
id-ID: Ketiga simpul jaringan ini melibatkan sejumlah antarmuka dengan nama-nama yang tidak biasa, seperti <filename>vif*</filename>, <filename>veth*</filename>, <filename>peth*</filename>, dan <filename>xenbr0</filename>. Hypervisor Xen mengatur mereka sesuai tata letak yang telah didefinisikan, di bawah kontrol perkakas pengguna. Karena NAT dan model routing hanya disesuaikan dengan kasus-kasus tertentu, kami hanya akan membahas model bridge.

en: After rebooting to make sure the bridge is automatically created, we can now start the domU with the Xen control tools, in particular the <command>xl</command> command. This command allows different manipulations on the domains, including listing them and, starting/stopping them. You might need to increase the default memory by editing the variable memory from configuration file (in this case, <filename>/etc/xen/testxen.cfg</filename>). Here we have set it to 1024 (megabytes).
id-ID: Setelah reboot untuk memastikan bridge secara otomatis dibuat, kita sekarang dapat memulai domU dengan perkakas kendali Xen, khususnya perintah <command>xl</command>. Perintah ini memungkinkan manipulasi yang berbeda pada domain, termasuk menampilkan daftar mereka dan, memulai/menghentikan mereka. Anda mungkin perlu menaikkan memori default dengan menyunting memori variabel dari berkas konfigurasi (dalam kasus ini, <filename>/etc/xen/testxen.cfg</filename>). Di sini kami telah mengaturnya ke 1024 (megabyte).

en: <emphasis>TOOL</emphasis> Choice of toolstacks to manage Xen VM
id-ID: <emphasis>PERKAKAS</emphasis> Pilihan kumpulan perkakas untuk mengelola VM Xen

en: <emphasis>CAUTION</emphasis> Only one domU per image!
id-ID: <emphasis>HATI-HATI</emphasis> Hanya satu domU per image!

en: While it is of course possible to have several domU systems running in parallel, they will all need to use their own image, since each domU is made to believe it runs on its own hardware (apart from the small slice of the kernel that talks to the hypervisor). In particular, it isn't possible for two domU systems running simultaneously to share storage space. If the domU systems are not run at the same time, it is, however, quite possible to reuse a single swap partition, or the partition hosting the <filename>/home</filename> filesystem.
id-ID: Meskipun tentu mungkin untuk memiliki beberapa sistem domU yang berjalan secara paralel, mereka semua perlu untuk menggunakan image mereka sendiri, karena setiap domU dibuat percaya ini berjalan pada perangkat keras sendiri (terlepas dari sepotong kecil kernel yang berbicara kepada hypervisor). Secara khusus, tidak mungkin bagi dua sistem domU berjalan bersamaan untuk berbagi ruang penyimpanan. Jika sistem domU tidak berjalan pada saat yang sama, sangat mungkin untuk menggunakan kembali satu partisi swap, atau partisi yang mewadahi sistem berkas <filename>/home</filename>.

en: Note that the <filename>testxen</filename> domU uses real memory taken from the RAM that would otherwise be available to the dom0, not simulated memory. Care should therefore be taken, when building a server meant to host Xen instances, to provision the physical RAM accordingly.
id-ID: Perhatikan bahwa domU <filename>testxen</filename> menggunakan memori nyata yang diambil dari RAM yang bila tidak demikian, tidak akan tersedia bagi dom0, bukan memori yang tersimulasi. Karena itu perlu hati-hati ketika membangun sebuah server yang dimaksudkan untuk mewadahi instansi Xen, untuk menyediakan RAM fisik yang sesuai.

en: Voilà! Our virtual machine is starting up. We can access it in one of two modes. The usual way is to connect to it “remotely” through the network, as we would connect to a real machine; this will usually require setting up either a DHCP server or some DNS configuration. The other way, which may be the only way if the network configuration was incorrect, is to use the <filename>hvc0</filename> console, with the <command>xl console</command> command:
id-ID: Voilà! Mesin virtual kami memulai. Kita dapat mengaksesnya dengan satu dari dua mode. Cara yang biasa adalah untuk menyambung "jarak jauh" melalui jaringan, seperti kita akan menyambung ke mesin nyata; ini biasanya akan memerlukan mendirikan penyiapan server DHCP atau beberapa konfigurasi DNS. Cara lain, yang mungkin satu-satunya cara jika konfigurasi jaringan salah, adalah dengan menggunakan konsol <filename>hvc0</filename>, dengan perintah <command>xl console</command>:

en: One can then open a session, just like one would do if sitting at the virtual machine's keyboard. Detaching from this console is achieved through the <keycombo action="simul"><keycap>Control</keycap> <keycap>]</keycap></keycombo> key combination.
id-ID: Kita kemudian dapat membuka sesi, seperti yang orang akan lakukan jika duduk di papan ketik mesin virtual. Melepaskan dari konsol ini dicapai melalui kombinasi tombol <keycombo action="simul"> <keycap>Control</keycap> <keycap>]</keycap></keycombo>.

en: <emphasis>TIP</emphasis> Getting the console straight away
id-ID: <emphasis>TIPS</emphasis> Mendapatkan konsol langsung

en: Sometimes one wishes to start a domU system and get to its console straight away; this is why the <command>xl create</command> command takes a <literal>-c</literal> switch. Starting a domU with this switch will display all the messages as the system boots.
id-ID: Kadang-kadang kita berharap untuk memulai sistem domU dan langsun mendapatkan konsol; inilah sebabnya mengapa perintah <command>xl create</command> menerima opsi <literal>-c</literal>. Memulai domU dengan switch ini akan menampilkan semua pesan ketika sistem boot.

en: Once the domU is up, it can be used just like any other server (since it is a GNU/Linux system after all). However, its virtual machine status allows some extra features. For instance, a domU can be temporarily paused then resumed, with the <command>xl pause</command> and <command>xl unpause</command> commands. Note that even though a paused domU does not use any processor power, its allocated memory is still in use. It may be interesting to consider the <command>xl save</command> and <command>xl restore</command> commands: saving a domU frees the resources that were previously used by this domU, including RAM. When restored (or unpaused, for that matter), a domU doesn't even notice anything beyond the passage of time. If a domU was running when the dom0 is shut down, the packaged scripts automatically save the domU, and restore it on the next boot. This will of course involve the standard inconvenience incurred when hibernating a laptop computer, for instance; in particular, if the domU is suspended for too long, network connections may expire. Note also that Xen is so far incompatible with a large part of ACPI power management, which precludes suspending the host (dom0) system.
id-ID: Setelah domU hidup, itu dapat digunakan seperti server lain (karena itu adalah sistem GNU/Linux juga). Namun, status mesin virtual memungkinkan beberapa fitur tambahan. Sebagai contoh, domU dapat diistirahatkan sementara kemudian dilanjutkan kembali, dengan perintah <command>xl pause</command> dan <command>xl unpause</command>. Perhatikan bahwa meskipun domU yang diistirahatkan tidak menggunakan prosesor apapun, memori yang dialokasikan masih digunakan. Mungkin menarik untuk mempertimbangkan perintah <command>xl save</command> dan <command>xl restore</command>: menyimpan domU membebaskan sumber daya yang sebelumnya digunakan oleh domU ini, termasuk RAM. Ketika dipulihkan (atau dilanjutkan kembali), domU bahkan tidak melihat apapun selain berlalunya waktu. Jika domU sedang berjalan ketika dom0 dimatikan, skrip yang dikemas secara otomatis menyimpan domU, dan memulihkannya pada boot berikutnya. Ini tentu saja akan melibatkan ketidaknyamanan standar yang timbul ketika menhibernasi komputer laptop misalnya; khususnya, jika domU disuspensi terlalu lama, koneksi jaringan mungkin berakhir. Perhatikan juga bahwa Xen sejauh ini tidak kompatibel dengan sebagian besar manajemen daya ACPI, yang menghalangi mensuspensi sistem host (dom0).

en: Halting or rebooting a domU can be done either from within the domU (with the <command>shutdown</command> command) or from the dom0, with <command>xl shutdown</command> or <command>xl reboot</command>.
id-ID: Menghentikan atau reboot domU dapat dilakukan baik dari dalam domU (dengan perintah <command>shutdown</command>) atau dari dom0, dengan <command>xl shutdown</command> atau <command>xl reboot</command>.

en: Most of the <command>xl</command> subcommands expect one or more arguments, often a domU name. These arguments are well described in the <citerefentry><refentrytitle>xl</refentrytitle> <manvolnum>1</manvolnum></citerefentry> manual page.
id-ID: Sebagian besar sub perintah <command>xl</command> mengharapkan satu atau lebih argumen, sering kali nama domU. Argumen ini dijelaskan dengan baik dalam halaman manual <citerefentry><refentrytitle>xl</refentrytitle> <manvolnum>1</manvolnum></citerefentry>.

en: <emphasis>GOING FURTHER</emphasis> Advanced Xen
id-ID: <emphasis>LEBIH JAUH</emphasis> Xen tingkat lanjut

en: Xen has many more features than we can describe in these few paragraphs. In particular, the system is very dynamic, and many parameters for one domain (such as the amount of allocated memory, the visible hard drives, the behavior of the task scheduler, and so on) can be adjusted even when that domain is running. A domU can even be migrated across servers without being shut down, and without losing its network connections! For all these advanced aspects, the primary source of information is the official Xen documentation. <ulink type="block" url="https://xenproject.org/help/documentation/" />
id-ID: Xen memiliki lebih banyak fitur daripada yang dapat kita gambarkan dalam beberapa paragraf ini. Secara khusus, sistem ini sangat dinamis, dan banyak parameter untuk satu domain (seperti banyaknya memori yang dialokasikan, hard drive yang terlihat, perilaku penjadwal tugas, dan sebagainya) dapat disesuaikan bahkan ketika domain tersebut sedang berjalan. DomU bahkan dapat dimigrasi lintas server tanpa dimatikan, dan tanpa kehilangan koneksi jaringannya! Untuk semua aspek canggih ini, sumber utama informasi adalah dokumentasi Xen resmi. <ulink type="block" url="https://xenproject.org/help/documentation/" />

en: Even though it is used to build “virtual machines”, LXC is not, strictly speaking, a virtualization system, but a system to isolate groups of processes from each other even though they all run on the same host. It takes advantage of a set of recent evolutions in the Linux kernel, collectively known as <emphasis>control groups</emphasis>, by which different sets of processes called “groups” have different views of certain aspects of the overall system. Most notable among these aspects are the process identifiers, the network configuration, and the mount points. Such a group of isolated processes will not have any access to the other processes in the system, and its accesses to the filesystem can be restricted to a specific subset. It can also have its own network interface and routing table, and it may be configured to only see a subset of the available devices present on the system.
id-ID: Meskipun hal ini digunakan untuk membangun "mesin virtual", LXC bukanlah, secara tegas, suatu sistem virtualisasi, tetapi sebuah sistem untuk mengisolasi kelompok proses dari satu sama lain meskipun mereka semua berjalan pada host yang sama. Ini memanfaatkan evolusi baru-baru ini pada kernel Linux, yang secara kolektif dikenal sebagai <emphasis>grup kendali</emphasis>, dimana set proses yang disebut "grup" yang berbeda memiliki pandangan yang berbeda atas aspek-aspek tertentu dari sistem secara keseluruhan. Paling menonjol di antara aspek-aspek ini adalah pengidentifikasi proses, konfigurasi jaringan, dan titik kait. Sebuah kelompok proses terisolasi tidak akan memiliki akses ke proses lain dalam sistem, dan aksesnya ke sistem berkas dapat dibatasi ke subset spesifik. Itu dapat juga memiliki antarmuka jaringan dan tabel routing sendiri, dan mungkin dikonfigurasi untuk hanya melihat subset dari perangkat yang tersedia yang ada pada sistem.

en: These features can be combined to isolate a whole process family starting from the <command>init</command> process, and the resulting set looks very much like a virtual machine. The official name for such a setup is a “container” (hence the LXC moniker: <emphasis>LinuX Containers</emphasis>), but a rather important difference with “real” virtual machines such as provided by Xen or KVM is that there is no second kernel; the container uses the very same kernel as the host system. This has both pros and cons: advantages include excellent performance due to the total lack of overhead, and the fact that the kernel has a global vision of all the processes running on the system, so the scheduling can be more efficient than it would be if two independent kernels were to schedule different task sets. Chief among the inconveniences is the impossibility to run a different kernel in a container (whether a different Linux version or a different operating system altogether).
id-ID: Fitur ini dapat dikombinasikan untuk mengisolasi keluarga seluruh proses yang dimulai dari proses <command>init</command>, dan kumpulan yang dihasilkan terlihat sangat mirip dengan mesin virtual. Nama resmi untuk penyiapan seperti itu adalah "container" (maka moniker LXC: <emphasis>LinuX Containers</emphasis>), tapi perbedaan yang cukup penting dengan mesin virtual "nyata" seperti yang disediakan oleh Xen atau KVM adalah bahwa tidak ada kernel kedua; container menggunakan kernel yang sama dengan sistem host. Ini memiliki pro dan kontra: keuntungannya termasuk kinerja yang sangat baik karena total ketiadaan overhead, dan fakta bahwa kernel memiliki visi global dari semua proses yang berjalan pada sistem, sehingga penjadwalan dapat menjadi lebih efisien daripada jika dua kernel independen yang menjadwalkan set tugas yang berbeda. Paling utama di antara ketidaknyamanan adalah ketidakmungkinan untuk menjalankan sebuah kernel yang berbeda dalam container (apakah versi Linux yang berbeda atau sistem operasi yang berbeda sama sekali).

en: <emphasis>NOTE</emphasis> LXC isolation limits
id-ID: <emphasis>CATATAN</emphasis> Batas isolasi LXC

en: LXC containers do not provide the level of isolation achieved by heavier emulators or virtualizers. In particular:
id-ID: Container LXC tidak memberikan tingkat isolasi yang dicapai oleh emulator atau virtualizers yang lebih berat. Khususnya:

en: since the kernel is shared among the host system and the containers, processes constrained to containers can still access the kernel messages, which can lead to information leaks if messages are emitted by a container;
id-ID: karena kernel dipakai bersama antara sistem host dan container, proses yang dibatasi ke container masih dapat mengakses pesan kernel, yang dapat menyebabkan kebocoran informasi jika pesan dipancarkan oleh kontainer;

en: for similar reasons, if a container is compromised and a kernel vulnerability is exploited, the other containers may be affected too;
id-ID: untuk alasan yang sama, jika sebuah container terganggu dan kerentanan kernel dieksploitasi, container lain mungkin akan terpengaruh juga;

en: on the filesystem, the kernel checks permissions according to the numerical identifiers for users and groups; these identifiers may designate different users and groups depending on the container, which should be kept in mind if writable parts of the filesystem are shared among containers.
id-ID: pada sistem berkas, kernel memeriksa izin menurut pengenal numerik untuk pengguna dan kelompok; pengidentifikasi ini dapat menetapkan pengguna dan kelompok yang berbeda tergantung pada container tersebut, yang harus diingat jika bagian-bagian yang dapat ditulisi dari sistem berkas dipakai bersama diantara wadah.

en: Since we are dealing with isolation and not plain virtualization, setting up LXC containers is more complex than just running debian-installer on a virtual machine. We will describe a few prerequisites, then go on to the network configuration; we will then be able to actually create the system to be run in the container.
id-ID: Karena kita berhadapan dengan isolasi dan virtualisasi yang tidak polos, menyiapkan container LXC lebih kompleks daripada hanya menjalankan debian-installer pada mesin virtual. Kami akan menjelaskan beberapa prasyarat, kemudian pergi ke konfigurasi jaringan; kami kemudian akan dapat benar-benar membuat sistem untuk dijalankan dalam container.

en: Preliminary Steps
id-ID: Langkah Pendahuluan

en: The <emphasis role="pkg">lxc</emphasis> package contains the tools required to run LXC, and must therefore be installed.
id-ID: Paket <emphasis role="pkg">lxc</emphasis> berisi alat-alat yang diperlukan untuk menjalankan LXC, dan karenanya harus dipasang.

en: LXC also requires the <emphasis>control groups</emphasis> configuration system, which is a virtual filesystem to be mounted on <filename>/sys/fs/cgroup</filename>. Since Debian 8 switched to systemd, which also relies on control groups, this is now done automatically at boot time without further configuration.
id-ID: LXC juga memerlukan sistem konfigurasi <emphasis>control group</emphasis>, yang berupa sistem berkas virtual untuk dipasang pada <filename>/sys/fs/cgroup</filename>. Karena Debian 8 beralih ke systemd, yang juga bergantung pada control group, hal ini sekarang dilakukan secara otomatis saat boot tanpa konfigurasi lebih lanjut.

en: Network Configuration
id-ID: Konfigurasi Jaringan

en: The goal of installing LXC is to set up virtual machines; while we could, of course, keep them isolated from the network, and only communicate with them via the filesystem, most use cases involve giving at least minimal network access to the containers. In the typical case, each container will get a virtual network interface, connected to the real network through a bridge. This virtual interface can be plugged either directly onto the host's physical network interface (in which case the container is directly on the network), or onto another virtual interface defined on the host (and the host can then filter or route traffic). In both cases, the <emphasis role="pkg">bridge-utils</emphasis> package will be required.
id-ID: Tujuan dari memasang LXC adalah untuk menyiapkan mesin virtual; walaupun tentu saja kita bisa menjaga mereka terisolasi dari jaringan, dan hanya berkomunikasi dengan mereka melalui sistem berkas, penggunaan umumnya memberikan setidaknya akses jaringan minimum ke container. Dalam kasus yang tipikal, masing-masing akan mendapatkan antarmuka jaringan virtual, yang terhubung ke jaringan nyata melalui sebuah bridge. Antarmuka virtual ini dapat dipasang langsung ke antarmuka jaringan fisik host (dalam hal ini container langsung berada pada jaringan) atau ke antarmuka virtual lain yang didefinisikan pada host (dan host kemudian dapat menyaring atau mengarahkan lalu lintas). Dalam kedua kasus, paket <emphasis role="pkg">bridge-utils</emphasis> akan diperlukan.

en: They should be disabled and replaced with the following:
id-ID: Mereka harus dinonaktifkan dan diganti dengan yang berikut:

en: The effect of this configuration will be similar to what would be obtained if the containers were machines plugged into the same physical network as the host. The “bridge” configuration manages the transit of Ethernet frames between all the bridged interfaces, which includes the physical <literal>eth0</literal> as well as the interfaces defined for the containers.
id-ID: Efek dari konfigurasi ini akan mirip dengan apa yang dapat diperoleh jika container itu adalah mesin yang terhubung ke jaringan fisik yang sama seperti host. Konfigurasi "jbridge" mengelola transit dari frame-frame Ethernet antara semua antarmuka yang dijembatani, yang mencakup fisik <literal>eth0</literal> maupun antarmuka yang didefinisikan untuk container.

en: In cases where this configuration cannot be used (for instance, if no public IP addresses can be assigned to the containers), a virtual <emphasis>tap</emphasis> interface will be created and connected to the bridge. The equivalent network topology then becomes that of a host with a second network card plugged into a separate switch, with the containers also plugged into that switch. The host must then act as a gateway for the containers if they are meant to communicate with the outside world.
id-ID: Dalam kasus-kasus yang mana konfigurasi ini tidak dapat digunakan (misalnya, jika tidak ada alamat IP publik dapat diberikan ke container), antarmuka virtual <emphasis>tap</emphasis> akan dibuat dan terhubung dengan bridge. Topologi jaringan kemudian menjadi suatu host dengan kartu jaringan kedua yang ditancapkan ke sebuah switch yang terpisah, dengan container juga dicolokkan ke switch itu. Host kemudian mesti bertindak sebagai sebuah gateway untuk container jika mereka dimaksudkan untuk berkomunikasi dengan dunia luar.

en: In addition to <emphasis role="pkg">bridge-utils</emphasis>, this “rich” configuration requires the <emphasis role="pkg">vde2</emphasis> package; the <filename>/etc/network/interfaces</filename> file then becomes:
id-ID: Selain <emphasis role="pkg">bridge-utils</emphasis>, konfigurasi "kaya" ini memerlukan paket <emphasis role="pkg">vde2</emphasis>; berkas <filename>/etc/network/interfaces</filename> kemudian menjadi:

en: The network can then be set up either statically in the containers, or dynamically with DHCP server running on the host. Such a DHCP server will need to be configured to answer queries on the <literal>br0</literal> interface.
id-ID: Jaringan kemudian dapat diatur baik secara statis dalam container, atau secara dinamis dengan server DHCP yang berjalan pada host. Server DHCP tersebut perlu dikonfigurasi untuk menjawab pertanyaan pada antarmuka <literal>br0</literal>.

en: Setting Up the System
id-ID: Menyiapkan Sistem

en: Note that the filesystem is initially created in <filename>/var/cache/lxc</filename>, then moved to its destination directory. This allows creating identical containers much more quickly, since only copying is then required.
id-ID: Perhatikan bahwa sistem berkas awalnya dibuat di <filename>/var/cache/lxc</filename>, kemudian dipindah ke direktori tujuannya. Hal ini memungkinkan membuat container-container identik secara jauh lebih cepat, karena kemudian hanya perlu menyalin.

en: Note that the Debian template creation script accepts an <option>--arch</option> option to specify the architecture of the system to be installed and a <option>--release</option> option if you want to install something else than the current stable release of Debian. You can also set the <literal>MIRROR</literal> environment variable to point to a local Debian mirror.
id-ID: Perhatikan bahwa skrip penciptaan templat Debian menerima pilihan <option>--arch</option> untuk menentukan arsitektur sistem yang akan diinstal dan pilihan <option>--release</option> jika Anda ingin menginstal sesuatu yang lain daripada rilis stabil Debian. Anda juga dapat menetapkan variabel lingkungan <literal>MIRROR</literal> untuk menunjuk ke mirror Debian lokal.

en: Another useful entry in that file is the setting of the hostname:
id-ID: Entri lain yang berguna dalam berkas itu adalah pengaturan nama host:

en: Starting the Container
id-ID: Memulai Container

en: We are now in the container; our access to the processes is restricted to only those started from the container itself, and our access to the filesystem is similarly restricted to the dedicated subset of the full filesystem (<filename>/var/lib/lxc/testlxc/rootfs</filename>). We can exit the console with <keycombo action="simul"><keycap>Control</keycap> <keycap>a</keycap></keycombo> <keycombo><keycap>q</keycap></keycombo>.
id-ID: Kita sekarang berada di dalam container; akses kita ke proses dibatasi ke hanya yang dimulai dari container itu sendiri, dan akses kita ke sistem berkas juga dibatasi ke subset yang terdedikasi dari sistem berkas penuh (<filename>/var/lib/lxc/testlxc/rootfs</filename>). Kita dapat keluar dari konsol dengan <keycombo action="simul"><keycap>Kontrol</keycap> <keycap>a</keycap></keycombo> <keycombo><keycap>q</keycap></keycombo>.

en: The <emphasis role="pkg">lxc</emphasis> package contains an initialization script that can automatically start one or several containers when the host boots (it relies on <command>lxc-autostart</command> which starts containers whose <literal>lxc.start.auto</literal> option is set to 1). Finer-grained control of the startup order is possible with <literal>lxc.start.order</literal> and <literal>lxc.group</literal>: by default, the initialization script first starts containers which are part of the <literal>onboot</literal> group and then the containers which are not part of any group. In both cases, the order within a group is defined by the <literal>lxc.start.order</literal> option.
id-ID: Paket <emphasis role="pkg">lxc</emphasis> berisi skrip inisialisasi yang dapat secara otomatis memulai satu atau beberapa container ketika host mem-boot (bergantung pada <command>lxc-autostart</command> yang memulai container yang opsi <literal>lxc.start.auto</literal> diberi nilai 1). Kontrol urutan startup yang lebih baik dimungkinkan dengan <literal>lxc.start.order</literal> dan <literal>lxc.group</literal>: secara default, skrip inisialisasi pertama-tama memulai container yang merupakan bagian dari grup <literal>onboot</literal> dan kemudian container yang bukan bagian dari grup manapun. Dalam kedua kasus, urutan dalam grup ditentukan oleh opsi <literal>lxc.start.order</literal>.

en: <emphasis>GOING FURTHER</emphasis> Mass virtualization
id-ID: <emphasis>LEBIH JAUH</emphasis> Virtualisasi masal

en: Since LXC is a very lightweight isolation system, it can be particularly adapted to massive hosting of virtual servers. The network configuration will probably be a bit more advanced than what we described above, but the “rich” configuration using <literal>tap</literal> and <literal>veth</literal> interfaces should be enough in many cases.
id-ID: Karena LXC adalah sebuah sistem isolasi yang sangat ringan, itu dapat diadaptasi untuk hosting besar-besaran dari server-server virtual. Konfigurasi jaringan mungkin akan sedikit lebih lanjut dari apa yang dijelaskan di atas, tetapi konfigurasi "kaya" menggunakan antarmuka <literal>tap</literal> dan <literal>veth</literal> mestinya cukup untuk banyak kasus.

en: It may also make sense to share part of the filesystem, such as the <filename>/usr</filename> and <filename>/lib</filename> subtrees, so as to avoid duplicating the software that may need to be common to several containers. This will usually be achieved with <literal>lxc.mount.entry</literal> entries in the containers configuration file. An interesting side-effect is that the processes will then use less physical memory, since the kernel is able to detect that the programs are shared. The marginal cost of one extra container can then be reduced to the disk space dedicated to its specific data, and a few extra processes that the kernel must schedule and manage.
id-ID: Mungkin juga masuk akal untuk berbagi bagian dari sistem berkas, seperti sub pohon <filename>/usr</filename> dan <filename>/lib</filename>, untuk menghindari duplikasi perangkat lunak yang mungkin perlu sama untuk beberapa container. Ini biasanya akan dicapai dengan entri <literal>lxc.mount.entry</literal> di berkas konfigurasi container. Efek samping yang menarik adalah bahwa proses kemudian akan menggunakan memori fisik yang lebih kecil, karena kernel mampu mendeteksi bahwa program dipakai bersama. Biaya marjinal dari satu container tambahan kemudian dikurangi menjadi ruang disk yang didedikasikan untuk data tertentu, dan beberapa proses tambahan yang harus dijadwalkan dan dikelola oleh kernel.

en: We haven't described all the available options, of course; more comprehensive information can be obtained from the <citerefentry> <refentrytitle>lxc</refentrytitle> <manvolnum>7</manvolnum> </citerefentry> and <citerefentry> <refentrytitle>lxc.container.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual pages and the ones they reference.
id-ID: Kami tentu saja belum menguraikan semua pilihan yang tersedia; informasi lebih lengkap dapat diperoleh dari halaman manual <citerefentry><refentrytitle>lxc</refentrytitle> <manvolnum>7</manvolnum></citerefentry> dan <citerefentry><refentrytitle>lxc.container.conf</refentrytitle> <manvolnum>5</manvolnum> </citerefentry> dan yang mereka acu.

en: Virtualization with KVM
id-ID: Virtualisasi dengan KVM

en: KVM, which stands for <emphasis>Kernel-based Virtual Machine</emphasis>, is first and foremost a kernel module providing most of the infrastructure that can be used by a virtualizer, but it is not a virtualizer by itself. Actual control for the virtualization is handled by a QEMU-based application. Don't worry if this section mentions <command>qemu-*</command> commands: it is still about KVM.
id-ID: KVM, kependekan dari <emphasis>Kernel-based Virtual Machine</emphasis>, adalah pertama dan terutama sebuah modul kernel yang menyediakan sebagian besar infrastruktur yang dapat digunakan oleh virtualizer, tetapi bukan virtualizer itu sendiri. Kontrol aktual untuk virtualisasi ditangani oleh sebuah aplikasi berbasis QEMU. Jangan khawatir jika bagian ini menyebutkan perintah <command>qemu-*</command>: itu masih tentang KVM.

en: Unlike other virtualization systems, KVM was merged into the Linux kernel right from the start. Its developers chose to take advantage of the processor instruction sets dedicated to virtualization (Intel-VT and AMD-V), which keeps KVM lightweight, elegant and not resource-hungry. The counterpart, of course, is that KVM doesn't work on any computer but only on those with appropriate processors. For x86-based computers, you can verify that you have such a processor by looking for “vmx” or “svm” in the CPU flags listed in <filename>/proc/cpuinfo</filename>.
id-ID: Tidak seperti sistem virtualisasi lain, KVM digabungkan ke kernel Linux sejak dari awal. Para pengembangnya memilih untuk mengambil keuntungan dari set instruksi prosesor yang didedikasikan untuk virtualisasi (Intel-VT dan AMD-V), yang menjaga KVM ringan, elegan, dan tidak boros sumber daya. Kekurangannya, tentu saja, adalah bahwa KVM tidak bekerja pada sebarang komputer tetapi hanya pada yang memiliki prosesor yang sesuai. Untuk komputer berbasis x86, Anda dapat memastikan bahwa Anda memiliki prosesor seperti itu dengan mencari "vmx" atau "svm" di bendera CPU yang tercantum dalam <filename>/proc/cpuinfo</filename>.

en: With Red Hat actively supporting its development, KVM has more or less become the reference for Linux virtualization.
id-ID: Dengan Red Hat secara aktif mendukung perkembangannya, KVM kurang lebih telah menjadi acuan untuk virtualisasi Linux.

en: We first install the required packages, with <command>apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer</command>. <emphasis role="pkg">libvirt-daemon-system</emphasis> provides the <command>libvirtd</command> daemon, which allows (potentially remote) management of the virtual machines running of the host, and starts the required VMs when the host boots. <emphasis role="pkg">libvirt-clients</emphasis> provides the <command>virsh</command> command-line tool, which allows controlling the <command>libvirtd</command>-managed machines.
id-ID: Kita pertama kali menginstal paket-paket yang diperlukan, dengan <command>apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer</command>. <emphasis role="pkg">libvirt-daemon-system</emphasis> menyediakan daemon <command>libvirtd</command>, yang memungkinkan manajemen mesin virtual (berpotensi remote) yang berjalan pada host, dan memulai VM yang diperlukan ketika host boot. <emphasis role="pkg">libvirt-clients</emphasis> menyediakan alat bantu baris perintah <command>virsh</command>, yang memungkinkan mengendalikan mesin-mesin yang dikelola oleh <command>libvirtd</command>.

en: The <emphasis role="pkg">virtinst</emphasis> package provides <command>virt-install</command>, which allows creating virtual machines from the command line. Finally, <emphasis role="pkg">virt-viewer</emphasis> allows accessing a VM's graphical console.
id-ID: Paket <emphasis role="pkg">virtinst</emphasis> menyediakan <command>virt-install</command>, yang memungkinkan membuat mesin virtual dari baris perintah. Terakhir, <emphasis role="pkg">virt-viewer</emphasis> memungkinkan mengakses sebuah konsol grafis VM.

en: Just as in Xen and LXC, the most frequent network configuration involves a bridge grouping the network interfaces of the virtual machines (see <xref linkend="sect.lxc.network" />).
id-ID: Sama seperti Xen dan LXC, konfigurasi jaringan yang paling sering melibatkan bridge yang mengelompokkan antarmuka jaringan mesin virtual (lihat <xref linkend="sect.lxc.network" />).

en: Alternatively, and in the default configuration provided by KVM, the virtual machine is assigned a private address (in the 192.168.122.0/24 range), and NAT is set up so that the VM can access the outside network.
id-ID: Sebagai alternatif, dan dalam konfigurasi default yang disediakan oleh KVM, mesin virtual diberikan alamat pribadi (di kisaran 192.168.122.0/24), dan NAT diatur sehingga VM dapat mengakses jaringan luar.

en: The rest of this section assumes that the host has an <literal>eth0</literal> physical interface and a <literal>br0</literal> bridge, and that the former is connected to the latter.
id-ID: Sisa bagian ini mengasumsikan bahwa host memiliki antarmuka fisik <literal>eth0</literal> dan bridge <literal>br0</literal>, dan bahwa yang terdahulu terhubung ke yang terakhir.

en: Installation with <command>virt-install</command>
id-ID: Instalasi dengan <command>virt-install</command>

en: Creating a virtual machine is very similar to installing a normal system, except that the virtual machine's characteristics are described in a seemingly endless command line.
id-ID: Membuat mesin virtual sangat mirip dengan menginstal sistem normal, kecuali bahwa karakteristik mesin virtual dijelaskan dalam baris perintah yang tampaknya tak berujung.

en: Practically speaking, this means we will use the Debian installer, by booting the virtual machine on a virtual DVD-ROM drive that maps to a Debian DVD image stored on the host system. The VM will export its graphical console over the VNC protocol (see <xref linkend="sect.remote-desktops" /> for details), which will allow us to control the installation process.
id-ID: Secara praktis, ini berarti kita akan menggunakan installer Debian, dengan mem-boot mesin virtual pada drive DVD-ROM virtual yang memetakan ke image DVD Debian yang tersimpan di sistem host. VM akan mengekspor konsol grafisnya lewat protokol VNC (lihat <xref linkend="sect.remote-desktops" /> untuk rincian), yang akan memungkinkan kita untuk mengontrol proses instalasi.

en: <emphasis>TIP</emphasis> Add your user to the libvirt group
id-ID: <emphasis>TIPS</emphasis> Menambahkan pengguna Anda ke grup libvirt

en: All samples in this section assume that you are running commands as root. Effectively, if you want to control a local libvirt daemon, you need either to be root or to be a member of the <literal>libvirt</literal> group (which is not the case by default). Thus if you want to avoid using root rights too often, you can add yourself to the <literal>libvirt</literal> group and run the various commands under your user identity.
id-ID: Semua contoh dalam bagian ini mengasumsikan bahwa Anda menjalankan perintah sebagai root. Secara efektif, jika Anda ingin mengontrol daemon libvirt lokal, Anda perlu untuk menjadi root atau menjadi anggota dari kelompok <literal>libvirt</literal> (yang tidak terjadi secara default). Jadi jika Anda ingin menghindari menggunakan hak root terlalu sering, Anda dapat menambahkan diri Anda sendiri ke grup <literal>libvirt</literal> dan menjalankan berbagai perintah di bawah identitas pengguna Anda.

en: Let us now start the installation process for the virtual machine, and have a closer look at <command>virt-install</command>'s most important options. This command registers the virtual machine and its parameters in libvirtd, then starts it so that its installation can proceed.
id-ID: Mari kita sekarang mulai proses instalasi untuk mesin virtual, dan melihat lebih dekat pada pilihan-pilihan <command>virt-install</command> yang paling penting. Perintah ini mendaftarkan mesin virtual dan parameternya di libvirtd, kemudian memulainya sehingga instalasi dapat dilanjutkan.

en: The <literal>--connect</literal> option specifies the “hypervisor” to use. Its form is that of an URL containing a virtualization system (<literal>xen://</literal>, <literal>qemu://</literal>, <literal>lxc://</literal>, <literal>openvz://</literal>, <literal>vbox://</literal>, and so on) and the machine that should host the VM (this can be left empty in the case of the local host). In addition to that, and in the QEMU/KVM case, each user can manage virtual machines working with restricted permissions, and the URL path allows differentiating “system” machines (<literal>/system</literal>) from others (<literal>/session</literal>).
id-ID: Opsi <literal>--connect</literal> menyatakan"hypervisor" yang akan dipakai. Bentuknya adalah URL yang memuat sistem virtualisasi (<literal>xen://</literal>, <literal>qemu://</literal>, <literal>lxc://</literal>, <literal>openvz://</literal>, <literal>vbox://</literal>, dan seterusnya) dan mesin yang harus menjadi host VM (ini dapat dibiarkan kosong dalam kasus hosting lokal). Selain itu, dan dalam kasus QEMU/KVM, setiap pengguna dapat mengelola mesin virtual yang bekerja dengan izin terbatas, dan path URL memungkinkan membedakan mesin "sistem" (<literal>/system</literal>) dari (<literal>/session</literal>) yang lain.

en: Since KVM is managed the same way as QEMU, the <literal>--virt-type kvm</literal> allows specifying the use of KVM even though the URL looks like QEMU.
id-ID: Karena KVM dikelola dengan cara yang sama seperti QEMU, <literal>--virt-type kvm</literal> mengizinkan menyatakan penggunaan KVM meskipun URL terlihat seperti QEMU.

en: The <literal>--name</literal> option defines a (unique) name for the virtual machine.
id-ID: Opsi <literal>--name</literal> mendefinisikan nama (unik) untuk mesin virtual.

en: The <literal>--memory</literal> option allows specifying the amount of RAM (in MB) to allocate for the virtual machine.
id-ID: Opsi <literal>--memory</literal> memungkinkan menentukan banyaknya RAM (dalam MB) yang dialokasikan untuk mesin virtual.

en: The <literal>--disk</literal> specifies the location of the image file that is to represent our virtual machine's hard disk; that file is created, unless present, with a size (in GB) specified by the <literal>size</literal> parameter. The <literal>format</literal> parameter allows choosing among several ways of storing the image file. The default format (<literal>qcow2</literal>) allows starting with a small file that only grows when the virtual machine starts actually using space.
id-ID: <literal>--disk</literal> menyatakan lokasi berkas image yang mewakili hard disk mesin virtual; berkas itu dibuat, kecuali sudah ada, dengan ukuran (dalam GB) yang ditentukan oleh parameter <literal>size</literal>. Parameter <literal>format</literal> memungkinkan memilih antara beberapa cara untuk menyimpan berkas image. Format default (<literal>qcow2</literal>) memungkinkan mulai dengan berkas kecil yang hanya tumbuh ketika mesin virtual mulai benar-benar menggunakan ruang.

en: The <literal>--cdrom</literal> option is used to indicate where to find the optical disk to use for installation. The path can be either a local path for an ISO file, an URL where the file can be obtained, or the device file of a physical CD-ROM drive (i.e. <literal>/dev/cdrom</literal>).
id-ID: Opsi <literal>--cdrom</literal> digunakan untuk menunjukkan di mana menemukan disk optik yang digunakan untuk instalasi. Path bisa berupa path lokal untuk berkas ISO, URL tempat berkas dapat diperoleh, atau perangkat berkas dari drive CD-ROM fisik (yaitu <literal>/dev/cdrom</literal>).

en: The <literal>--network</literal> specifies how the virtual network card integrates in the host's network configuration. The default behavior (which we explicitly forced in our example) is to integrate it into any pre-existing network bridge. If no such bridge exists, the virtual machine will only reach the physical network through NAT, so it gets an address in a private subnet range (192.168.122.0/24).
id-ID: <literal>--network</literal> menyatakan bagaimana kartu jaringan virtual mengintegrasi dalam konfigurasi jaringan host. Perilaku default (yang secara eksplisit kita paksa dalam contoh kita) adalah mengintegrasikannya ke dalam jaringan bridge apapun yang sudah ada. Jika bridge seperti itu tidak ada, mesin virtual hanya akan mencapai jaringan fisik melalui NAT, sehingga mendapat alamat di subnet pribadi (192.168.122.0/24).

en: <literal>--graphics vnc</literal> states that the graphical console should be made available using VNC. The default behavior for the associated VNC server is to only listen on the local interface; if the VNC client is to be run on a different host, establishing the connection will require setting up an SSH tunnel (see <xref linkend="sect.ssh-port-forwarding" />). Alternatively, <literal>--graphics vnc,listen=0.0.0.0</literal> can be used so that the VNC server is accessible from all interfaces; note that if you do that, you really should design your firewall accordingly.
id-ID: <literal>--graphics vnc</literal> menyatakan bahwa konsol grafis harus dibuat tersedia menggunakan VNC. Perilaku default untuk server VNC terkait adalah hanya mendengarkan pada antarmuka lokal; jika klien VNC akan dijalankan pada host yang berbeda, membuat koneksi akan memerlukan pengaturan tunnel SSH (lihat <xref linkend="sect.ssh-port-forwarding" />). Sebagai alternatif, <literal>--graphics vnc,listen=0.0.0.0</literal> dapat digunakan sehingga server VNC dapat diakses dari semua antarmuka; perhatikan bahwa jika Anda melakukannya, Anda benar-benar harus merancang firewall Anda sesuai dengan itu.

en: The <literal>--os-type</literal> and <literal>--os-variant</literal> options allow optimizing a few parameters of the virtual machine, based on some of the known features of the operating system mentioned there.
id-ID: Pilihan <literal>--os-type</literal> dan <literal>--os-variant</literal> memungkinkan mengoptimalkan beberapa parameter mesin virtual, berdasarkan fitur yang dikenal dari sistem operasi yang disebutkan di sana.

en: At this point, the virtual machine is running, and we need to connect to the graphical console to proceed with the installation process. If the previous operation was run from a graphical desktop environment, this connection should be automatically started. If not, or if we operate remotely, <command>virt-viewer</command> can be run from any graphical environment to open the graphical console (note that the root password of the remote host is asked twice because the operation requires 2 SSH connections):
id-ID: Pada titik ini, mesin virtual sedang berjalan, dan kita perlu terhubung ke konsol grafis untuk melanjutkan dengan proses instalasi. Jika operasi sebelumnya berjalan dari lingkungan desktop grafis, hubungan ini harus secara otomatis dimulai. Jika tidak, atau jika kita beroperasi jarak jauh, <command>virt-viewer</command> dapat dijalankan dari setiap lingkungan grafis untuk membuka konsol grafis (perhatikan bahwa kata sandi root dari host remote diminta dua kali karena operasi memerlukan 2 koneksi SSH):

en: When the installation process ends, the virtual machine is restarted, now ready for use.
id-ID: Ketika proses instalasi berakhir, mesin virtual dijalankan ulang, sekarang siap untuk digunakan.

en: Managing Machines with <command>virsh</command>
id-ID: Mengelola Mesin dengan <command>virsh</command>

en: Now that the installation is done, let us see how to handle the available virtual machines. The first thing to try is to ask <command>libvirtd</command> for the list of the virtual machines it manages:
id-ID: Sekarang setelah instalasi selesai, mari kita lihat bagaimana menangani mesin virtual yang tersedia. Hal pertama yang dicoba adalah untuk bertanya ke <command>libvirtd</command> daftar mesin virtual yang dikelolanya:

en: Let's start our test virtual machine:
id-ID: Mari kita mulai jalankan mesin virtual uji kita:

en: We can now get the connection instructions for the graphical console (the returned VNC display can be given as parameter to <command>vncviewer</command>):
id-ID: Kita sekarang bisa mendapatkan petunjuk koneksi untuk konsol grafis (tampilan VNC yang dikembalikan dapat diberikan sebagai parameter ke <command>vncviewer</command>):

en: Other available <command>virsh</command> subcommands include:
id-ID: Sub perintah <command>virsh</command> lain yang tersedia meliputi:

en: <literal>reboot</literal> to restart a virtual machine;
id-ID: <literal>reboot</literal> untuk memulai jalankan lagi sebuah mesin virtual;

en: <literal>shutdown</literal> to trigger a clean shutdown;
id-ID: <literal>shutdown</literal> untuk memicu suatu shutdown yang bersih;

en: <literal>destroy</literal>, to stop it brutally;
id-ID: <literal>destroy</literal>, untuk menghentikannya secara brutal;

en: <literal>suspend</literal> to pause it;
id-ID: <literal>suspend</literal> untuk mengistirahatkannya;

en: <literal>resume</literal> to unpause it;
id-ID: <literal>resume</literal> untuk melanjutkan dari istirahat;

en: <literal>autostart</literal> to enable (or disable, with the <literal>--disable</literal> option) starting the virtual machine automatically when the host starts;
id-ID: <literal>autostart</literal> untuk mengaktifkan (atau menonaktifkan, dengan pilihan <literal>--disable</literal>) memulai mesin virtual secara otomatis ketika host mulai;

en: <literal>undefine</literal> to remove all traces of the virtual machine from <command>libvirtd</command>.
id-ID: <literal>undefine</literal> untuk menghapus semua jejak mesin virtual dari <command>libvirtd</command>.

en: All these subcommands take a virtual machine identifier as a parameter.
id-ID: Semua sub perintah ini mengambil sebuah identifier mesin virtual sebagai parameter.

en: Automated Installation
id-ID: Pemasangan Otomatis

en: <primary>deployment</primary>
id-ID: <primary>penggelaran</primary>

en: <primary>installation</primary><secondary>automated installation</secondary>
id-ID: <primary>instalasi</primary><secondary>instalasi terotomasi</secondary>

en: The Falcot Corp administrators, like many administrators of large IT services, need tools to install (or reinstall) quickly, and automatically if possible, their new machines.
id-ID: Administrator Falcot Corp, seperti banyak administrator dari layanan TI yang besar, membutuhkan alat untuk menginstal (atau menginstal ulang) dengan cepat, dan secara otomatis jika mungkin, mesin-mesin baru mereka.

en: These requirements can be met by a wide range of solutions. On the one hand, generic tools such as SystemImager handle this by creating an image based on a template machine, then deploy that image to the target systems; at the other end of the spectrum, the standard Debian installer can be preseeded with a configuration file giving the answers to the questions asked during the installation process. As a sort of middle ground, a hybrid tool such as FAI (<emphasis>Fully Automatic Installer</emphasis>) installs machines using the packaging system, but it also uses its own infrastructure for tasks that are more specific to massive deployments (such as starting, partitioning, configuration and so on).
id-ID: Persyaratan ini dapat dipenuhi oleh berbagai macam solusi. Di satu sisi, alat-alat generik seperti SystemImager menangani hal ini dengan menciptakan sebuah image yang didasarkan pada mesin templat, kemudian menyebarkan image ke sistem target; di ujung lain spektrum, penginstal Debian standar dapat diprabibit dengan berkas konfigurasi yang memberikan jawaban-jawaban untuk pertanyaan-pertanyaan yang ditanyakan selama proses instalasi. Sebagai semacam jalan tengah, alat hibrida seperti FAI (<emphasis>Fully Automatic Installer</emphasis>) menginstal mesin menggunakan sistem pemaketan, tetapi juga menggunakan infrastrukturnya sendiri untuk tugas-tugas yang lebih spesifik bagi penyebaran masif (seperti memulai, mempartisi, mengkonfigurasi, dan seterusnya).

en: Fully Automatic Installer (FAI)
id-ID: Fully Automatic Installer (FAI, Pemasang Otomatis Sepenuhnya)

en: <foreignphrase>Fully Automatic Installer</foreignphrase> is probably the oldest automated deployment system for Debian, which explains its status as a reference; but its very flexible nature only just compensates for the complexity it involves.
id-ID: <foreignphrase>Fully Automatic Installer</foreignphrase> mungkin adalah sistem penggelaran otomatis tertua untuk Debian, yang menjelaskan statusnya sebagai referensi; tetapi sifatnya yang sangat fleksibel hanya mengkompensasi kompleksitas yang melibatkannya.

en: FAI requires a server system to store deployment information and allow target machines to boot from the network. This server requires the <emphasis role="pkg">fai-server</emphasis> package (or <emphasis role="pkg">fai-quickstart</emphasis>, which also brings the required elements for a standard configuration).
id-ID: FAI memerlukan sebuah sistem server untuk menyimpan informasi penggelaran dan memungkinkan mesin target untuk boot dari jaringan. Server ini memerlukan paket <emphasis role="pkg">fai-server</emphasis> (atau <emphasis role="pkg">fai-quickstart</emphasis>, yang juga membawa elemen-elemen yang diperlukan untuk sebuah konfigurasi standar).

en: Creating all these configuration files requires some understanding of the way FAI works. A typical installation process is made of the following steps:
id-ID: Menciptakan semua berkas konfigurasi ini memerlukan pemahaman tentang cara FAI bekerja. Suatu proses instalasi biasanya tersusun dari langkah-langkah berikut:

en: fetching a kernel from the network, and booting it;
id-ID: mengambil sebuah kernel dari jaringan, dan mem-boot itu;

en: mounting the root filesystem from NFS;
id-ID: mengait sistem berkas root dari NFS;

en: executing <command>/usr/sbin/fai</command>, which controls the rest of the process (the next steps are therefore initiated by this script);
id-ID: mengeksekusi <command>/usr/sbin/fai</command>, yang mengontrol seluruh proses (langkah berikutnya karena itu diprakarsai oleh skrip ini);

en: copying the configuration space from the server into <filename>/fai/</filename>;
id-ID: menyalin ruang konfigurasi dari server ke <filename>/fai/</filename>;

en: running <command>fai-class</command>. The <filename>/fai/class/[0-9][0-9]*</filename> scripts are executed in turn, and return names of “classes” that apply to the machine being installed; this information will serve as a base for the following steps. This allows for some flexibility in defining the services to be installed and configured.
id-ID: menjalankan <command>fai-class</command>. Skrip <filename>/fai/class/[0-9][0-9]*</filename> dijalankan sesuai gilirannya, dan mengembalikan nama "kelas" yang berlaku untuk mesin yang diinstal; informasi ini akan berfungsi sebagai dasar untuk langkah-langkah berikut. Hal ini memungkinkan untuk beberapa fleksibilitas dalam mendefinisikan layanan yang akan diinstal dan dikonfigurasi.

en: fetching a number of configuration variables, depending on the relevant classes;
id-ID: mengambil sejumlah variabel konfigurasi, tergantung pada kelas yang relevan;

en: partitioning the disks and formatting the partitions, based on information provided in <filename>/fai/disk_config/<replaceable>class</replaceable></filename>;
id-ID: mempartisi disk dan memformat partisi, berdasarkan informasi yang diberikan dalam <filename>/fai/disk_config/<replaceable>kelas</replaceable></filename>;

en: mounting said partitions;
id-ID: mengaitkan partisi yang disebut;

en: installing the base system;
id-ID: memasang sistem dasar;

en: preseeding the Debconf database with <command>fai-debconf</command>;
id-ID: memprabibit basis data Debconf dengan <command>fai-debconf</command>;

en: fetching the list of available packages for APT;
id-ID: mengambil daftar paket yang tersedia untuk APT;

en: installing the packages listed in <filename>/fai/package_config/<replaceable>class</replaceable></filename>;
id-ID: menginstal paket-paket yang tercantum dalam <filename>/fai/package_config/<replaceable>kelas</replaceable></filename>;

en: executing the post-configuration scripts, <filename>/fai/scripts/<replaceable>class</replaceable>/[0-9][0-9]*</filename>;
id-ID: menjalankan skrip pasca konfigurasi, <filename>/fai/scripts/<replaceable>kelas</replaceable>/[0-9][0-9]*</filename>;

en: recording the installation logs, unmounting the partitions, and rebooting.
id-ID: merekam log instalasi, melepas kait partisi, dan reboot.

en: Preseeding Debian-Installer
id-ID: Memprabibit Debian-Installer

en: <primary>preconfiguration</primary>
id-ID: <primary>prakonfigurasi</primary>

en: <emphasis>GOING FURTHER</emphasis> Debconf with a centralized database
id-ID: <emphasis>LEBIH JAUH</emphasis> Debconf dengan suatu basis data terpusat

en: Preseeding allows to provide a set of answers to Debconf questions at installation time, but these answers are static and do not evolve as time passes. Since already-installed machines may need upgrading, and new answers may become required, the <filename>/etc/debconf.conf</filename> configuration file can be set up so that Debconf uses external data sources (such as an LDAP directory server, or a remote file accessed via NFS or Samba). Several external data sources can be defined at the same time, and they complement one another. The local database is still used (for read-write access), but the remote databases are usually restricted to reading. The <citerefentry><refentrytitle>debconf.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual page describes all the possibilities in detail (you need the <emphasis role="pkg">debconf-doc</emphasis> package).
id-ID: Prabibit memungkinkan untuk memberikan serangkaian jawaban ke pertanyaan Debconf pada saat instalasi, tetapi jawaban ini bersifat statis dan tidak berkembang seiring berjalannya waktu. Karena mesin yang sudah terpasang mungkin perlu ditingkatkan, dan jawaban baru dapat menjadi diperlukan, berkas konfigurasi <filename>/etc/debconf.conf</filename> dapat mengatur sehingga Debconf menggunakan sumber data eksternal (seperti sebuah direktori LDAP server, atau berkas jarak jauh yang diakses melalui NFS atau Samba). Beberapa sumber data eksternal dapat didefinisikan pada saat yang sama, dan mereka melengkapi satu sama lain. Basis data lokal masih digunakan (untuk akses baca-tulis), tetapi basis data jarak jauh biasanya dibatasi untuk hanya baca. Halaman manual <citerefentry><refentrytitle>debconf.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> menjelaskan semua kemungkinan secara rinci (Anda perlu paket <emphasis role="pkg">debconf-doc</emphasis>).

en: Using a Preseed File
id-ID: Menggunakan Berkas Preseed

en: There are several places where the installer can get a preseeding file:
id-ID: Ada beberapa tempat dimana installer bisa memperoleh berkas preseed:

en: in the initrd used to start the machine; in this case, preseeding happens at the very beginning of the installation, and all questions can be avoided. The file just needs to be called <filename>preseed.cfg</filename> and stored in the initrd root.
id-ID: di initrd yang digunakan untuk memulai mesin; dalam kasus ini, prabibit terjadi pada awal instalasi, dan semua pertanyaan dapat dihindari. Berkas hanya perlu disebut <filename>preseed.cfg</filename> dan disimpan dalam root initrd.

en: on the boot media (CD or USB key); preseeding then happens as soon as the media is mounted, which means right after the questions about language and keyboard layout. The <literal>preseed/file</literal> boot parameter can be used to indicate the location of the preseeding file (for instance, <filename>/cdrom/preseed.cfg</filename> when the installation is done off a CD-ROM, or <filename>/hd-media/preseed.cfg</filename> in the USB-key case).
id-ID: pada media boot (CD atau kunci USB); prabibit kemudian terjadi segera setelah media dipasang, yang berarti tepat setelah pertanyaan tentang bahasa dan tata letak papan ketik. Parameter boot <literal>preseed/file</literal> dapat digunakan untuk menunjukkan lokasi berkas prabibit (misalnya, <filename>/cdrom/preseed.cfg</filename> ketika instalasi dilakukan dari CD-ROM, atau <filename>/hd-media/preseed.cfg</filename> dalam kasus kunci USB).

en: At a glance, including the preseeding file in the initrd looks like the most interesting solution; however, it is rarely used in practice, because generating an installer initrd is rather complex. The other two solutions are much more common, especially since boot parameters provide another way to preseed the answers to the first questions of the installation process. The usual way to save the bother of typing these boot parameters by hand at each installation is to save them into the configuration for <command>isolinux</command> (in the CD-ROM case) or <command>syslinux</command> (USB key).
id-ID: Sekilas, menyertakan berkas prabibit di initrd tampak seperti solusi yang paling menarik; namun, ini jarang digunakan dalam praktek, karena menghasilkan installer initrd agak rumit. Kedua solusi yang lain lebih umum, terutama karena parameter boot menyediakan cara lain untuk memprabibit jawaban atas pertanyaan pertama dari proses instalasi. Cara yang biasa untuk menghindari kerepotan mengetik parameter boot ini di setiap instalasi adalah dengan menyimpan mereka ke dalam konfigurasi untuk <command>isolinux</command> (dalam kasus CD-ROM) atau <command>syslinux</command> (kunci USB).

en: Creating a Preseed File
id-ID: Membuat Berkas Preseed

en: A preseed file is a plain text file, where each line contains the answer to one Debconf question. A line is split across four fields separated by whitespace (spaces or tabs), as in, for instance, <literal>d-i mirror/suite string stable</literal>:
id-ID: Prabibit adalah berkas teks biasa, dimana setiap baris berisi jawaban atas satu pertanyaan Debconf. Baris dipecah ke empat bidang yang dipisahkan oleh spasi atau tab, seperti, misalnya, <literal>d-i mirror/suite string stable</literal>:

en: the first field is the “owner” of the question; “d-i” is used for questions relevant to the installer, but it can also be a package name for questions coming from Debian packages;
id-ID: bidang pertama adalah "pemilik" pertanyaan; "d-i" digunakan untuk pertanyaan-pertanyaan yang relevan dengan installer, tetapi juga bisa berupa nama paket untuk pertanyaan-pertanyaan yang datang dari paket-paket Debian;

en: third, the type of question;
id-ID: ketiga, jenis pertanyaan;

en: the fourth and last field contains the value for the answer. Note that it must be separated from the third field with a single space; if there are more than one, the following space characters are considered part of the value.
id-ID: ke empat dan ruas terakhir memuat nilai untuk jawaban. Perhatikan bahwa ini harus dipisahkan dari ruas ke tiga dengan satu spasi; jika ada lebih dari satu, karakter spasi yang mengikuti dianggap bagian dari nilai.

en: The simplest way to write a preseed file is to install a system by hand. Then <command>debconf-get-selections --installer</command> will provide the answers concerning the installer. Answers about other packages can be obtained with <command>debconf-get-selections</command>. However, a cleaner solution is to write the preseed file by hand, starting from an example and the reference documentation: with such an approach, only questions where the default answer needs to be overridden can be preseeded; using the <literal>priority=critical</literal> boot parameter will instruct Debconf to only ask critical questions, and use the default answer for others.
id-ID: Cara termudah untuk menulis berkas preseed adalah untuk menginstal sebuah sistem dengan tangan. Kemudian <command>debconf-get-selections --installer</command> akan memberikan jawaban tentang installer. Jawaban tentang paket lainnya dapat diperoleh dengan <command>debconf-get-selections</command>. Namun, solusi yang lebih bersih adalah dengan menulis berkas preseed dengan tangan, mulai dari contoh dan dokumentasi referensi: dengan pendekatan seperti itu, hanya pertanyaan yang jawaban bakunya perlu ditimpa dapat diprabibit; menggunakan parameter boot <literal>priority=critical</literal> akan menginstruksikan Debconf untuk hanya mengajukan pertanyaan yang kritis, dan menggunakan jawaban baku bagi yang lain.

en: <emphasis>DOCUMENTATION</emphasis> Installation guide appendix
id-ID: <emphasis>DOKUMENTASI</emphasis> Lampiran panduan instalasi

en: Creating a Customized Boot Media
id-ID: Membuat sebuah Media Boot Ubahan

en: Knowing where to store the preseed file is all very well, but the location isn't everything: one must, one way or another, alter the installation boot media to change the boot parameters and add the preseed file.
id-ID: Mengetahui di mana untuk menyimpan berkas preseed itu baik, tapi lokasi bukan segalanya: kita harus, dengan satu cara atau lainnya, mengubah media boot instalasi untuk mengubah parameter boot dan menambahkan berkas preseed.

en: Booting From the Network
id-ID: Boot dari Jaringan

en: When a computer is booted from the network, the server sending the initialization elements also defines the boot parameters. Thus, the change needs to be made in the PXE configuration for the boot server; more specifically, in its <filename>/tftpboot/pxelinux.cfg/default</filename> configuration file. Setting up network boot is a prerequisite; see the Installation Guide for details. <ulink type="block" url="https://www.debian.org/releases/stable/amd64/ch04s05" />
id-ID: Ketika komputer di-boot dari jaringan, server mengirimkan elemen inisialisasi juga mendefinisikan parameter boot. Dengan demikian, perubahan perlu dibuat dalam konfigurasi PXE untuk server boot; lebih khusus lagi, dalam berkas konfigurasi <filename>/tftpboot/pxelinux.cfg/default</filename>. Pengaturan boot jaringan merupakan prasyarat; lihat Panduan Instalasi untuk rincian. <ulink type="block" url="https://www.debian.org/releases/stable/amd64/ch04s05" />

en: Preparing a Bootable USB Key
id-ID: Mempersiapkan sebuah Flash Disk USB yang Dapat Di-boot

en: syslinux.cfg file and preseeding parameters
id-ID: berkas syslinux.cfg dan parameter preseed

en: Creating a CD-ROM Image
id-ID: Membuat suatu Image CD-ROM

en: A USB key is a read-write media, so it was easy for us to add a file there and change a few parameters. In the CD-ROM case, the operation is more complex, since we need to regenerate a full ISO image. This task is handled by <emphasis role="pkg">debian-cd</emphasis>, but this tool is rather awkward to use: it needs a local mirror, and it requires an understanding of all the options provided by <filename>/usr/share/debian-cd/CONF.sh</filename>; even then, <command>make</command> must be invoked several times. <filename>/usr/share/debian-cd/README</filename> is therefore a very recommended read.
id-ID: Kunci USB adalah media baca-tulis, jadi mudah bagi kita untuk menambahkan berkas ke sana dan mengubah beberapa parameter. Dalam kasus CD-ROM, operasi lebih kompleks, karena kita perlu melakukan regenerasi image ISO penuh. Tugas ini ditangani oleh <emphasis role="pkg">debian-cd</emphasis>, tapi alat ini agak aneh untuk digunakan: dibutuhkan cermin lokal, dan itu memerlukan pemahaman tentang semua pilihan yang disediakan oleh <filename>/usr/share/debian-cd/CONF.sh</filename>; bahkan kemudian, <command>make</command> harus dipanggil beberapa kali. <filename>/usr/share/debian-cd/README</filename> sangat dianjurkan untuk dibaca.

en: Simple-CDD: The All-In-One Solution
id-ID: Simple-CDD: Solusi Semua-Jadi-Satu

en: Simply using a preseed file is not enough to fulfill all the requirements that may appear for large deployments. Even though it is possible to execute a few scripts at the end of the normal installation process, the selection of the set of packages to install is still not quite flexible (basically, only “tasks” can be selected); more important, this only allows installing official Debian packages, and precludes locally-generated ones.
id-ID: Hanya menggunakan berkas preseed ini tidak cukup untuk memenuhi semua persyaratan yang mungkin muncul untuk penggelaran besar. Meskipun dimungkinkan untuk mengeksekusi beberapa skrip pada akhir proses penginstalan normal, pemilihan set paket yang akan diinstal ini tetap tidak cukup fleksibel (pada dasarnya, hanya "task" yang dapat dipilih); lebih penting, ini hanya memungkinkan menginstal paket-paket Debian yang resmi, dan mencegah dipasangnya yang dihasilkan secara lokal.

en: Creating Profiles
id-ID: Menciptakan Profil

en: Simple-CDD defines “profiles” that match the FAI “classes” concept, and a machine can have several profiles (determined at installation time). A profile is defined by a set of <filename>profiles/<replaceable>profile</replaceable>.*</filename> files:
id-ID: Simple-CDD mendefinisikan "profil" yang sesuai dengan konsep "kelas" FAI, dan sebuah mesin dapat memiliki beberapa profil (yang ditentukan pada saat instalasi). Profil didefinisikan oleh satu set berkas <filename>profiles/<replaceable>profil</replaceable>.*</filename>:

en: the <filename>.description</filename> file contains a one-line description for the profile;
id-ID: berkas <filename>.description</filename> berisi satu baris deskripsi untuk profil;

en: the <filename>.packages</filename> file lists packages that will automatically be installed if the profile is selected;
id-ID: berkas <filename>.packages</filename> berisi daftar paket yang akan secara otomatis diinstal jika profil dipilih;

en: the <filename>.downloads</filename> file lists packages that will be stored onto the installation media, but not necessarily installed;
id-ID: berkas <filename>.downloads</filename> berisi daftar paket yang akan disimpan ke media instalasi, tetapi tidak harus diinstal;

en: the <filename>.preseed</filename> file contains preseeding information for Debconf questions (for the installer and/or for packages);
id-ID: berkas <filename>.preseed</filename> berisi informasi preseed untuk pertanyaan Debconf (untuk installer dan atau paket);

en: the <filename>.postinst</filename> file contains a script that will be run at the end of the installation process;
id-ID: berkas <filename>.postinst</filename> berisi skrip yang akan dijalankan pada akhir proses instalasi;

en: The <literal>default</literal> profile has a particular role, since it is always selected; it contains the bare minimum required for Simple-CDD to work. The only thing that is usually customized in this profile is the <literal>simple-cdd/profiles</literal> preseed parameter: this allows avoiding the question, introduced by Simple-CDD, about what profiles to install.
id-ID: Profil <literal>default</literal> memiliki peran tertentu, karena selalu dipilih; ini berisi minimal yang diperlukan oleh Simple-CDD untuk bekerja. Satu-satunya hal yang biasanya disesuaikan dalam profil ini adalah parameter preseed <literal>simple-cdd/profiles</literal>: hal ini memungkinkan menghindari pertanyaan, diperkenalkan oleh Simple-CDD, tentang profil apa yang akan dipasang.

en: Note also that the commands will need to be invoked from the parent directory of the <filename>profiles</filename> directory.
id-ID: Perhatikan juga bahwa perintah akan perlu dijalankan dari direktori induk direktori <filename>profil</filename>.

en: Configuring and Using <command>build-simple-cdd</command>
id-ID: Mengkonfigurasi dan Menggunakan <command>build-simple-cdd</command>

en: <emphasis>QUICK LOOK</emphasis> Detailed configuration file
id-ID: <emphasis>LIHAT SEKILAS</emphasis> Berkas konfigurasi rinci

en: Simple-CDD requires many parameters to operate fully. They will most often be gathered in a configuration file, which <command>build-simple-cdd</command> can be pointed at with the <literal>--conf</literal> option, but they can also be specified via dedicated parameters given to <command>build-simple-cdd</command>. Here is an overview of how this command behaves, and how its parameters are used:
id-ID: Simple-CDD memerlukan banyak parameter untuk beroperasi secara penuh. Mereka akan paling sering dikumpulkan dalam berkas konfigurasi, yang dapat diarahkan ke <command>build-simple-cdd</command> dengan opsi <literal>--conf</literal>, tetapi mereka dapat juga ditentukan melalui parameter khusus yang diberikan kepada <command>build-simple-cdd </command>. Berikut ini adalah gambaran bagaimana perintah ini berperilaku, dan bagaimana parameternya digunakan:

en: the <literal>profiles</literal> parameter lists the profiles that will be included on the generated CD-ROM image;
id-ID: parameter <literal>profil</literal> memuat daftar profil yang akan disertakan pada CD-ROM image yang dihasilkan;

en: based on the list of required packages, Simple-CDD downloads the appropriate files from the server mentioned in <literal>server</literal>, and gathers them into a partial mirror (which will later be given to debian-cd);
id-ID: berdasarkan daftar paket yang diperlukan, Simple-CDD mengunduh berkas-berkas yang sesuai dari server yang disebutkan di <literal>server</literal>, dan mengumpulkan mereka menjadi cermin parsial (yang akan kemudian diberikan kepada debian-cd);

en: the custom packages mentioned in <literal>local_packages</literal> are also integrated into this local mirror;
id-ID: paket ubahan yang dicantumkan dalam <literal>local_packages</literal> juga diintegrasikan ke dalam cermin lokal ini;

en: debian-cd is then executed (within a default location that can be configured with the <literal>debian_cd_dir</literal> variable), with the list of packages to integrate;
id-ID: debian-cd kemudian dijalankan (dalam lokasi baku yang dapat dikonfigurasi dengan variabel <literal>debian_cd_dir</literal>), dengan daftar paket untuk diintegrasikan;

en: once debian-cd has prepared its directory, Simple-CDD applies some changes to this directory:
id-ID: setelah debian-cd menyiapkan direktorinya, Simple-CDD menerapkan beberapa perubahan ke direktori ini:

en: files containing the profiles are added in a <filename>simple-cdd</filename> subdirectory (that will end up on the CD-ROM);
id-ID: berkas yang berisi profil ditambahkan dalam subdirektori <filename>simple-cdd</filename> (yang akan berakhir pada CD-ROM);

en: other files listed in the <literal>all_extras</literal> parameter are also added;
id-ID: berkas lain yang tercantum dalam <literal>all_extras</literal> parameter juga ditambahkan;

en: the boot parameters are adjusted so as to enable the preseeding. Questions concerning language and country can be avoided if the required information is stored in the <literal>language</literal> and <literal>country</literal> variables.
id-ID: parameter boot disesuaikan sehingga memungkinkan preseed. Pertanyaan mengenai bahasa dan negara dapat dihindari jika informasi yang diperlukan disimpan dalam variabel <literal>language</literal> dan <literal>country</literal>.

en: debian-cd then generates the final ISO image.
id-ID: debian-cd kemudian menghasilkan image ISO akhir.

en: Generating an ISO Image
id-ID: Menghasilkan suatu Image ISO

en: Monitoring is a generic term, and the various involved activities have several goals: on the one hand, following usage of the resources provided by a machine allows anticipating saturation and the subsequent required upgrades; on the other hand, alerting the administrator as soon as a service is unavailable or not working properly means that the problems that do happen can be fixed sooner.
id-ID: Pemantauan adalah istilah umum, dan berbagai kegiatan yang dilibatkan memiliki beberapa tujuan: di satu sisi, mengikuti penggunaan sumber daya yang disediakan oleh sebuah mesin memungkinkan mengantisipasi saturasi dan peningkatan berikutnya yang diperlukan; di sisi lain, memperingatkan administrator segera setelah layanan ini tidak tersedia atau tidak berfungsi sebagaimana mestinya berarti bahwa masalah yang terjadi dapat lebih cepat diperbaiki.

en: <emphasis>Munin</emphasis> covers the first area, by displaying graphical charts for historical values of a number of parameters (used RAM, occupied disk space, processor load, network traffic, Apache/MySQL load, and so on). <emphasis>Nagios</emphasis> covers the second area, by regularly checking that the services are working and available, and sending alerts through the appropriate channels (e-mails, text messages, and so on). Both have a modular design, which makes it easy to create new plug-ins to monitor specific parameters or services.
id-ID: <emphasis>Munin</emphasis> mencakup area pertama dengan menampilkan bagan grafis untuk riwayat nilai dari sejumlah parameter (RAM yang digunakan, ruang disk yang ditempati, beban prosesor, trafik jaringan, beban Apache/MySQL, dan seterusnya). <emphasis>Nagios</emphasis> mencakup daerah yang kedua, dengan secara teratur memeriksa bahwa layanan bekerja dan tersedia, dan mengirimkan peringatan melalui saluran yang tepat (surel, pesan teks, dan sebagainya). Keduanya memiliki desain modular, yang membuat mudah untuk menciptakan plug-in baru untuk memantau parameter atau layanan tertentu.

en: <emphasis>ALTERNATIVE</emphasis> Zabbix, an integrated monitoring tool
id-ID: <emphasis>ALTERNATIF</emphasis> Zabbix, alat pemantauan terintegrasi

en: <emphasis>ALTERNATIVE</emphasis> Icinga, a Nagios fork
id-ID: <emphasis>ALTERNATIF</emphasis> Icinga, suatu fork Nagios

en: Setting Up Munin
id-ID: Menyiapkan Munin

en: The purpose of Munin is to monitor many machines; therefore, it quite naturally uses a client/server architecture. The central host — the grapher — collects data from all the monitored hosts, and generates historical graphs.
id-ID: Tujuan dari Munin adalah untuk memantau banyak mesin; oleh karena itu, cukup alami menggunakan arsitektur klien server. Host pusat — grapher — mengumpulkan data dari semua host yang dipantau, dan menghasilkan grafik historis.

en: Configuring Hosts To Monitor
id-ID: Mengkonfigurasi Host yang Akan Dimonitor

en: The first step is to install the <emphasis role="pkg">munin-node</emphasis> package. The daemon installed by this package listens on port 4949 and sends back the data collected by all the active plugins. Each plugin is a simple program returning a description of the collected data as well as the latest measured value. Plugins are stored in <filename>/usr/share/munin/plugins/</filename>, but only those with a symbolic link in <filename>/etc/munin/plugins/</filename> are really used.
id-ID: Langkah pertama adalah untuk menginstal paket <emphasis role="pkg">munin-node</emphasis>. Daemon yang diinstal oleh paket ini mendengarkan pada port 4949 dan mengirimkan kembali data yang dikumpulkan oleh semua plugin aktif. Masing-masing plugin adalah program sederhana yang mengembalikan deskripsi dari data yang dikumpulkan serta nilai yang terakhir diukur. Plugin disimpan dalam <filename>/usr/share/munin/plugins/</filename>, tetapi hanya yang memiliki symlink di <filename>/etc/munin/plugins/</filename> yang benar-benar digunakan.

en: Once all plugins are correctly set up, the daemon configuration must be updated to describe access control for the collected data. This involves <literal>allow</literal> directives in the <filename>/etc/munin/munin-node.conf</filename> file. The default configuration is <literal>allow ^127\.0\.0\.1$</literal>, and only allows access to the local host. An administrator will usually add a similar line containing the IP address of the grapher host, then restart the daemon with <command>systemctl restart munin-node</command>.
id-ID: Setelah semua plugin yang benar diatur, konfigurasi daemon harus diperbarui untuk menggambarkan kontrol akses untuk data yang dikumpulkan. Ini melibatkan direktif <literal>allow</literal> dalam berkas <filename>/etc/munin/munin-node.conf</filename>. Konfigurasi default adalah <literal>allow ^127\.0\.0\.1$</literal>, dan hanya mengizinkan akses ke host lokal. Administrator biasanya akan menambahkan baris serupa yang berisi alamat IP host grapher, kemudian menjalankan ulang daemon dengan <command>systemctl restart munin-node</command>.

en: <emphasis>GOING FURTHER</emphasis> Creating local plugins
id-ID: <emphasis>LEBIH JAUH</emphasis> Membuat plugin lokal

en: A plugin is best tested when run in the same conditions as it would be when triggered by munin-node; this can be simulated by running <command>munin-run <replaceable>plugin</replaceable></command> as root. A potential second parameter given to this command (such as <literal>config</literal>) is passed to the plugin as a parameter.
id-ID: Sebuah plugin terbaik diuji ketika dijalankan dalam kondisi yang sama dengan ketika dipicu oleh munin-node; ini bisa disimulasikan dengan menjalankan <command>munin-run<replaceable>plugin</replaceable></command> sebagai root. Parameter potensial kedua yang diberikan kepada perintah ini (seperti misalnya <literal>config</literal>) dilewatkan ke plugin sebagai parameter.

en: When a plugin is invoked with the <literal>config</literal> parameter, it must describe itself by returning a set of fields:
id-ID: Ketika sebuah plugin dipanggil dengan parameter <literal>config</literal>, itu harus menguraikan dirinya sendiri dengan mengembalikan sekumpulan ruas:

en: The various available fields are described by the “Plugin reference” available as part of the “Munin guide”. <ulink type="block" url="https://munin.readthedocs.org/en/latest/reference/plugin.html" />
id-ID: Berbagai ruas yang tersedia dijelaskan oleh "Referensi plugin" yang tersedia sebagai bagian dari "Panduan Munin". <ulink type="block" url="https://munin.readthedocs.org/en/latest/reference/plugin.html" />

en: When invoked without a parameter, the plugin simply returns the last measured values; for instance, executing <command>sudo munin-run load</command> could return <literal>load.value 0.12</literal>.
id-ID: Ketika dipanggil tanpa parameter, plugin hanya mengembalikan nilai yang terakhir diukur; misalnya, menjalankan <command>sudo munin-run load</command> bisa mengembalikan <literal>load.value 0.12</literal>.

en: Finally, when a plugin is invoked with the <literal>autoconf</literal> parameter, it should return “yes” (and a 0 exit status) or “no” (with a 1 exit status) according to whether the plugin should be enabled on this host.
id-ID: Akhirnya, ketika sebuah plugin dipanggil dengan parameter <literal>autoconf</literal>, itu harus mengembalikan "yes" (dan status keluar 0) atau "no" (dengan status keluar 1) sesuai dengan apakah plugin harus diaktifkan pada host ini.

en: Configuring the Grapher
id-ID: Mengkonfigurasi Pembuat Grafik

en: The “grapher” is simply the computer that aggregates the data and generates the corresponding graphs. The required software is in the <emphasis role="pkg">munin</emphasis> package. The standard configuration runs <command>munin-cron</command> (once every 5 minutes), which gathers data from all the hosts listed in <filename>/etc/munin/munin.conf</filename> (only the local host is listed by default), saves the historical data in RRD files (<emphasis>Round Robin Database</emphasis>, a file format designed to store data varying in time) stored under <filename>/var/lib/munin/</filename> and generates an HTML page with the graphs in <filename>/var/cache/munin/www/</filename>.
id-ID: "grapher" adalah sekadar komputer yang mengumpulkan data dan menghasilkan grafik yang sesuai. Perangkat lunak yang diperlukan adalah dalam paket <emphasis role="pkg">munin</emphasis>. Konfigurasi standar menjalankan <command>munin-cron</command> (sekali setiap 5 menit), yang mengumpulkan data dari semua host yang tercantum dalam <filename>/etc/munin/munin.conf</filename> (hanya host lokal yang tercantum secara default), menyimpan data historis di berkas RRD (<emphasis>Round Robin Database</emphasis>, sebuah format berkas yang dirancang untuk menyimpan data yang bervariasi dalam waktu) disimpan di bawah <filename>/var/lib/munin/</filename> dan menghasilkan halaman HTML dengan grafik di <filename>/var/cache/munin/www/</filename>.

en: All monitored machines must therefore be listed in the <filename>/etc/munin/munin.conf</filename> configuration file. Each machine is listed as a full section with a name matching the machine and at least an <literal>address</literal> entry giving the corresponding IP address.
id-ID: Semua mesin yang dipantau oleh karena itu harus tercantum dalam berkas konfigurasi <filename>/etc/munin/munin.conf</filename>. Setiap mesin didaftar sebagai bagian penuh dengan suatu nama yang cocok dengan mesin dan setidaknya entri <literal>address</literal> yang memberikan alamat IP yang sesuai.

en: Sections can be more complex, and describe extra graphs that could be created by combining data coming from several machines. The samples provided in the configuration file are good starting points for customization.
id-ID: Seksi dapat menjadi lebih kompleks, dan menggambarkan grafik tambahan yang dapat dibuat dengan menggabungkan data yang berasal dari beberapa mesin. Sampel yang disediakan di berkas konfigurasi adalah titik awal yang baik untuk kustomisasi.

en: The last step is to publish the generated pages; this involves configuring a web server so that the contents of <filename>/var/cache/munin/www/</filename> are made available on a website. Access to this website will often be restricted, using either an authentication mechanism or IP-based access control. See <xref linkend="sect.http-web-server" /> for the relevant details.
id-ID: Langkah terakhir adalah untuk mempublikasikan halaman yang dihasilkan; ini melibatkan mengkonfigurasi server web sehingga isi <filename>/var/cache/munin/www/</filename> menjadi tersedia di situs web. Akses ke situs web ini akan sangat dibatasi, menggunakan mekanisme otentikasi atau kontrol akses berbasis IP. Lihat <xref linkend="sect.http-web-server" /> untuk rincian yang relevan.

en: Setting Up Nagios
id-ID: Menyiapkan Nagios

en: Unlike Munin, Nagios does not necessarily require installing anything on the monitored hosts; most of the time, Nagios is used to check the availability of network services. For instance, Nagios can connect to a web server and check that a given web page can be obtained within a given time.
id-ID: Tidak seperti Munin, Nagios tidak selalu membutuhkan memasang apapun pada host yang dipantau; sebagian besar waktu, Nagios digunakan untuk memeriksa ketersediaan layanan jaringan. Sebagai contoh, Nagios dapat menyambung ke server web dan memeriksa bahwa suatu halaman web dapat diperoleh dalam selang waktu tertentu.

en: Installing
id-ID: Memasang

en: The first step in setting up Nagios is to install the <emphasis role="pkg">nagios4</emphasis> and <emphasis role="pkg">monitoring-plugins</emphasis> packages. Installing the packages configures the web interface and the Apache server. The <literal>authz_groupfile</literal> and <literal>auth_digest</literal> Apache modules must be enabled, for that execute:
id-ID: Langkah pertama dalam menyiapkan Nagios adalah menginstal paket <emphasis role="pkg">nagios4</emphasis> dan <emphasis role="pkg">monitoring-plugins</emphasis>. Menginstal paket mengkonfigurasi antarmuka web dan server Apache. Modul Apache <literal>authz_groupfile</literal> dan <literal>auth_digest</literal> harus diaktifkan, untuk itu jalankan:

en: Adding other users is a simple matter of inserting them in the <filename>/etc/nagios4/hdigest.users</filename> file.
id-ID: Menambahkan pengguna lain cukup dengan memasukkannya ke dalam berkas <filename>/etc/nagios4/hdigest.users</filename>.

en: Pointing a browser at <literal>http://<replaceable>server</replaceable>/nagios4/</literal> displays the web interface; in particular, note that Nagios already monitors some parameters of the machine where it runs. However, some interactive features such as adding comments to a host do not work. These features are disabled in the default configuration for Nagios, which is very restrictive for security reasons.
id-ID: Mengarahkan peramban ke <literal>http://<replaceable>server</replaceable>/nagios4/</literal> menampilkan antarmuka web; secara khusus, perhatikan bahwa Nagios sudah memantau beberapa parameter mesin tempat dia berjalan. Namun, beberapa fitur interaktif seperti menambahkan komentar ke host tidak bekerja. Fitur ini dinonaktifkan dalam konfigurasi default untuk Nagios, yang sangat ketat untuk alasan keamanan.

en: Enabling some features involves editing <filename>/etc/nagios4/nagios.cfg</filename>. We also need to set up write permissions for the directory used by Nagios, with commands such as the following:
id-ID: Memfungsikan beberapa fitur melibatkan mengedit <filename>/etc/nagios4/nagios.cfg</filename>. Kita juga perlu untuk mengatur izin menulis direktori yang digunakan oleh Nagios, dengan perintah seperti berikut:

en: Configuring
id-ID: Mengkonfigurasi

en: The Nagios web interface is rather nice, but it does not allow configuration, nor can it be used to add monitored hosts and services. The whole configuration is managed via files referenced in the central configuration file, <filename>/etc/nagios4/nagios.cfg</filename>.
id-ID: Antarmuka web Nagios agak bagus, tetapi tidak memungkinkan konfigurasi, dan tidak bisa digunakan untuk menambah host dan layanan yang dipantau. Seluruh konfigurasi diatur melalui berkas-berkas yang dirujuk dalam berkas konfigurasi pusat, <filename>/etc/nagios4/nagios.cfg</filename>.

en: These files should not be dived into without some understanding of the Nagios concepts. The configuration lists objects of the following types:
id-ID: Berkas-berkas ini tidak boleh diselami tanpa pemahaman konsep-konsep Nagios. Konfigurasi memuat daftar objek jenis berikut:

en: a <emphasis>host</emphasis> is a machine to be monitored;
id-ID: suatu <emphasis>host</emphasis> adalah mesin yang akan dimonitor;

en: a <emphasis>hostgroup</emphasis> is a set of hosts that should be grouped together for display, or to factor some common configuration elements;
id-ID: suatu <emphasis>hostgroup</emphasis> adalah seperangkat host yang harus dikelompokkan menjadi satu untuk ditampilkan, atau untuk memfaktorkan beberapa elemen konfigurasi umum;

en: a <emphasis>service</emphasis> is a testable element related to a host or a host group. It will most often be a check for a network service, but it can also involve checking that some parameters are within an acceptable range (for instance, free disk space or processor load);
id-ID: suatu <emphasis>layanan</emphasis> adalah elemen yang dapat diuji terkait dengan host atau grup host. Paling sering akan berupa pengujian layanan jaringan, tetapi dapat juga melibatkan pemeriksaan bahwa beberapa parameter ada dalam rentang yang dapat diterima (misalnya, sisa ruang disk atau beban prosesor);

en: a <emphasis>servicegroup</emphasis> is a set of services that should be grouped together for display;
id-ID: suatu <emphasis>servicegroup</emphasis> adalah satu set layanan yang harus dikumpulkan bersama-sama untuk ditampilkan;

en: a <emphasis>contact</emphasis> is a person who can receive alerts;
id-ID: suatu <emphasis>contact</emphasis> adalah orang yang dapat menerima pemberitahuan;

en: a <emphasis>contactgroup</emphasis> is a set of such contacts;
id-ID: suatu <emphasis>contactgroup</emphasis> adalah sekumpulan kontak tersebut;

en: a <emphasis>timeperiod</emphasis> is a range of time during which some services have to be checked;
id-ID: suatu <emphasis>timeperiod</emphasis> adalah rentang waktu saat beberapa layanan harus diperiksa;

en: a <emphasis>command</emphasis> is the command line invoked to check a given service.
id-ID: suatu <emphasis>command</emphasis> adalah baris perintah yang dipanggil untuk memeriksa layanan yang diberikan.

en: According to its type, each object has a number of properties that can be customized. A full list would be too long to include, but the most important properties are the relations between the objects.
id-ID: Sesuai dengan jenisnya, setiap objek memiliki sejumlah properti yang dapat disesuaikan. Daftar lengkap akan terlalu panjang untuk disertakan, tapi properti yang paling penting adalah hubungan antar objek tersebut.

en: A <emphasis>service</emphasis> uses a <emphasis>command</emphasis> to check the state of a feature on a <emphasis>host</emphasis> (or a <emphasis>hostgroup</emphasis>) within a <emphasis>timeperiod</emphasis>. In case of a problem, Nagios sends an alert to all members of the <emphasis>contactgroup</emphasis> linked to the service. Each member is sent the alert according to the channel described in the matching <emphasis>contact</emphasis> object.
id-ID: Suatu <emphasis>service</emphasis> menggunakan <emphasis>command</emphasis> untuk memeriksa keadaan dari suatu fitur pada <emphasis>host</emphasis> (atau <emphasis>hostgroup</emphasis>) dalam <emphasis>timeperiod</emphasis>. Bila ada masalah, Nagios mengirimkan peringatan kepada semua anggota <emphasis>contactgroup</emphasis> yang terhubung ke layanan. Setiap anggota dikirim pesan peringatan menurut saluran yang dijelaskan dalam objek <emphasis>contact</emphasis> yang cocok.

en: An inheritance system allows easy sharing of a set of properties across many objects without duplicating information. Moreover, the initial configuration includes a number of standard objects; in many cases, defining new hosts, services and contacts is a simple matter of deriving from the provided generic objects. The files in <filename>/etc/nagios4/conf.d/</filename> are a good source of information on how they work.
id-ID: Suatu sistem warisan memungkinkan berbagi dengan mudah satu set properti ke banyak objek tanpa menggandakan informasi. Selain itu, konfigurasi awal mencakup sejumlah objek standar; dalam banyak kasus, mendefinisikan host baru, layanan, dan kontak cukup dengan menurunkan dari objek generik yang disediakan. Berkas-berkas dalam <filename>/etc/nagios4/conf.d/</filename> adalah sumber yang baik informasi tentang bagaimana mereka bekerja.

en: The Falcot Corp administrators use the following configuration:
id-ID: Para administrator Falcot Corp menggunakan konfigurasi berikut:

en: <filename>/etc/nagios4/conf.d/falcot.cfg</filename> file
id-ID: berkas <filename>/etc/nagios4/conf.d/falcot.cfg</filename>

en: This configuration file describes two monitored hosts. The first one is the web server, and the checks are made on the HTTP (80) and secure-HTTP (443) ports. Nagios also checks that an SMTP server runs on port 25. The second host is the FTP server, and the check includes making sure that a reply comes within 20 seconds. Beyond this delay, a <emphasis>warning</emphasis> is emitted; beyond 30 seconds, the alert is deemed critical. The Nagios web interface also shows that the SSH service is monitored: this comes from the hosts belonging to the <literal>ssh-servers</literal> hostgroup. The matching standard service is defined in <filename>/etc/nagios4/conf.d/services_nagios2.cfg</filename>.
id-ID: Berkas konfigurasi ini menjelaskan dua host yang dipantau. Yang pertama adalah server web, dan pemeriksaan dibuat pada port HTTP (80) dan HTTP aman (443). Nagios juga memeriksa bahwa server SMTP berjalan pada port 25. Host kedua adalah server FTP, dan pemeriksaan termasuk memastikan bahwa jawaban datang dalam 20 detik. Penundaan lebih dari ini, <emphasis>peringatan</emphasis> disebarkan; lebih dari 30 detik, pesan waspada dianggap kritis. Antarmuka web Nagios juga menunjukkan bahwa layanan SSH dipantau: ini datang dari host milik hostgroup <literal>ssh-servers</literal>. Layanan standar yang cocok didefinisikan dalam <filename>/etc/nagios4/conf.d/services_nagios2.cfg</filename>.

en: Note the use of inheritance: an object is made to inherit from another object with the “use <replaceable>parent-name</replaceable>”. The parent object must be identifiable, which requires giving it a “name <replaceable>identifier</replaceable>” property. If the parent object is not meant to be a real object, but only to serve as a parent, giving it a “register 0” property tells Nagios not to consider it, and therefore to ignore the lack of some parameters that would otherwise be required.
id-ID: Perhatikan penggunaan warisan: suatu objek dibuat untuk mewarisi dari objek lain dengan "menggunakan <replaceable>nama orang tua"</replaceable>. Objek induk harus dapat diidentifikasi, yang memerlukan memberikan sebuah properti "nama <replaceable>pengenal</replaceable>". Jika objek induk tidak dimaksudkan untuk menjadi sebuah objek yang nyata, tetapi hanya untuk melayani sebagai orang tua, memberinya sebuah properti "register 0" memberitahu Nagios untuk tidak untuk mempertimbangkan itu, dan karena itu untuk mengabaikan kekurangan beberapa parameter yang bila tidak demikian akan diperlukan.

en: <emphasis>DOCUMENTATION</emphasis> List of object properties
id-ID: <emphasis>DOKUMENTASI</emphasis> Daftar properti obyek

en: <emphasis>GOING FURTHER</emphasis> Remote tests with NRPE
id-ID: <emphasis>LEBIH JAUH</emphasis> Uji jarak jauh dengan NRPE
