November 2010 - Posts
Quick Migration adalah fitur yang terdapat baik pada Windows Server 2008 Hyper-V maupun Windows Server 2008 R2 Hyper-V. Tetapi, Live Migration hanya terdapat pada Windows Server 2008 R2. Perbedaan utama antara Live Migration dan Quick Migration adalah Live Migration memindahkan virtual machine tanpa terasa adanya downtime atau gangguan service. Kebutuhan untuk Live Migration dan Quick Migration hampir sama.
Baik Live Migration dan Quick Migration dapat diinisiasi dengan :
- Konsol System Center Virtual Machine Manager, jika Virtual Machine Manager mengelola cluster nodes yang dikonfigurasi untuk mendukung Live Migration atau Quick Migration.
Catatan: Dukungan untuk Live Migration akan dimasukkan dalam System Center Virtual Machine Manager 2008 R2.
- Konsol Failover Cluster Management, dimana administrator dapat melakukan inisiasi live migration.
- Script Windows Management Instrumentation (WMI).
Integrasi Live Migration dan Failover Clustering
Live Migration memerlukan dua persyaratan pokok: pertama butuh failover clustering di Windows Server 2008 R2; dan kedua membutuhkan shared disk storage antar cluster nodes. Shared disk storage dapat disediakan dengan solusi berbasis vendor hardware atau dengan fitur Cluster Shared Volumes di failover clustering di Windows Server 2008 R2.
Berikut ini adalah persyaratan untuk menjalankan Live Migration dengan failover cluster:
- Live Migration hanya dapat dijalankan antar cluster nodes dalam failover cluster yang sama (virtual machines hanya dapat dipindahkan antar cluster nodes).
- Hyper-V harus berjalan pada cluster nodes dalam failover cluster dan dapat mengakses shared disk storage yang sama, seperti yang disediakan oleh Cluster Shared Volumes atau yang berbasis manufaktur hardware.
- File-file .vhd untuk virtual machines yang dipindahkan oleh Live Migration harus tersimpan pada shared disk storage yang sama.
Gambar berikut mengilustrasikan sebuah tipikal dari Hyper-V dan konfigurasi failover cluster untuk mendukung Live Migration.
Gambar Konfigurasi Tipikal untuk mendukung Live Migration
Proses Live Migration
Proses Live Migration dijalakankan dengan langkah-langkah sebagai berikut:
1. Administrator Hyper-V melakukan inisiasi Live Migration antara cluster node sumber (Source virtual machine) dan cluster node target (Target virtual machine).
2. Duplikasi dari virtual machine dibuat pada target cluster node, seperti diilustrasikan pada gambar berikut. Cluster node sumber membuat koneksi TCP dengan cluster node target. Koneksi ini digunakan untuk mentransfer data konfigurasi virtual machine menuju ke cluster node target. Kerangka dari virtual machine VM dibuat pada cluster node target dan memori dialokasikan untuk virtual machine tujuan.
Gambar Pembuatan virtual machine target pada cluster node target
3. Seluruh memori pada virtual machine sumber dicopy ke virtual machine target. Memori yang diberikan pada virtual machine sumber dicopy via jaringan menuju ke virtual machine target. Memori ini disebut sebagai working set dari virtual machine sumber. Satu page memori berukuran 4 kilobytes.
Gambar Inisial copy dari sumber ke virtual machine
4. Client yang melakukan koneksi ke virtual machine sumber tetap melanjutkan untuk menggunakan virtual machine sumber dan membuat memory pages.
5. Hyper-V melakukan treking memory pages tersebut dan melakukan proses copy dari pages tersebut secara iteratif sampai seluruh memory pages dicopykan ke virtual machine target, seperti yang diilustrasikan pada gambar berikut ini.
Gambar Proses copy secara iteratif dari virtual machine sumber menuju virtual machine target
6. Ketika working set dari virtual machine sumber dicopykan, virtual machine sumber distop dan memory pages sisanya di-copykan. Catatan: Proses Live migration dapat saja dibatalkan (canceled) sebelum tahapan ini dalam migrasi. Selama tahapan dari migrasi ini, bandwidth jaringan yang tersedia antara cluster nodes sumber dan target merupakan bagian penting dalam kecepatan melakukan migrasi. Untuk alasan ini, 10 Gigabit yang disarankan antar cluster nodes. Kecepatan transmisi yang lebih cepat antar cluster nodes, akan menjamin proses penyelesaian migrasi yang lebih cepat lagi.
7. Storage yang menangani file-file .vhd ditransfer dari cluster node sumber ke cluster node target.
8. Ketika seluruh memory pages dicopykan ke virtual machine target dan storage yang menanganinya dipindahkan, machine target dinyalakan dan akses dari sisi client secara otomatis di redirect ke virtual machine target dan virtual machine sumber dihapus, seperti yang diilustrasikan pada gambar berikut ini.
Gambar konfigurasi akhir setelah proses Live Migration selesai dilakukan
9. Kemudian switch jaringan fisik akan mengupdate lokasi baru dari virtual machine yang dimigrasikan.
Proses Live Migration akan selesai lebih cepat dibanding TCP timeout interval untuk virtual machine yang dimigrasi. Interval dari TCP timeout bervariasi bergantung pada topologi jaringan dan faktor-faktor lain, kebanyakan migrasi akan selesai dilakukan dalam beberapa detik saja. Variabel berikut dapat memberikan dampak terhadap kecepatan migrasi:
- Ketersediaan badwidth jaringan antara host sumber dengan host tujuan
- Konfigurasi hardware host sumber dan host tujuan
- Beban/Load pada host sumber dan host tujuan
- Ketersediaan bandwidth jaringan antara host-host Hyper-V hosts dan shared storage
Ok, demikian tulisan sederhana ini, semoga dapat bermanfaat….
Menyambung artikel sebelumnya, masih erat kaitannya dengan Update Sequence Number (USN) di sini dan di sini, kali ini saya akan memaparkan pengertian yang sederhana tentang Originating Update dan Replicated Update dalam replikasi yang berlangsung antar domain controller di Windows Server 2008/2008 R2.
Replikasi yang berlangsung antar domain controller pada dasarnya ada dua tipe:
-
Originating Update (write) : Istilah ini untuk mendefinisikan tempat atau titik asal terjadinya update, pada domain controller yang melakukan perubahan pertama kali.
-
Replicated Update (write) : Istilah yang dipakai untuk menyatakan lawan dari originating update, perubahan tidak terjadi di sini, melainkan menerima hasil replikasi dari domain controller lain.
Jika kita menggunakan snap-in Active Directory Users and Computers untuk membuat tujuh user account pada DC01, maka USN dari DC tersebut akan bertambah tujuh kali. Perubahan ini kemudian direplikasi ke DC02, juga dengan menambahkan USN-nya sebanyak tujuh. Jika DC01 menerima suatu perubahan dari DC02, maka USN dari DC01 juga akan kembali bertambah. Penjelasan secara detail dapat dilihat pada table berikut.
Demikianlah coretan yang sederhana ini dan semoga dapat bermanfaat……
Tiap domain controller memelihara Update Sequence Number (USN). Tiap kali terdapat perubahan (objek baru, update, delete, dst) yang dilakukan terhadap Active Directory, maka akan muncul suatu transaksi (transaction). USN merupakan suatu nilai (64 bit value) yang diberikan pada tiap atomic update transaction, dan hanya bermanfaat dalam kaitannya dengan domain controller dimana update tersebut dilakukan. Tiap update transaction yang berbeda akan menghasilkan pertambahan nilai USN. Satu nilai USN dapat merepresentasikan perubahan pada semua atribut pada suatu objek atau bisa saja perubahan pada satu atribut dari satu objek. Jika kita periksa suatu nilai yaitu highest committed USN dari suatu domain controller dan menemukan nilai misalkan 1000, kemudian beberapa menit kemudian highest commited USN berubah menjadi 1056, maka dapat kita simpulkan telah terjadi 56 transaction yang terjadi pada waktu beberapa menit tersebut.
Pada directory system lain, selain Microsoft menggunakan timestamp untuk mengontrol replikasi dan untuk dipropagasi/ disebarkan dari server ke server, Microsoft menggunakan nilai USN. Dengan menggunakan USN, artinya menggunakan sistem dimana terdapat pertambahan nilai secara sequential (bukan timestamp) dan jelas bermanfaat dalam menghindari isu dari terdapatnya server-server yang salah di dalam setting clock-nya atau server tersebut gagal dalam proses sinkronisasi dengan replication partner-nya. Tiap domain controller memelihara masing-masing highest combined USN-nya untuk seluruh naming context di dalam nilai highestCommitedUSN dari RootDSE.
Kutipan dari ldp untuk proses query ke RootDSE hingga mendapatkan nilai highestCommittedUSN (gunakan perintah ldp.exe dari menu Run dan lakukan koneksi ke domain controller) sebagai berikut:
Jalankan perintah ldp.exe dari menu Run:
Klik menu Connection
Pada kotak Connect, isikan nama server domain controllernya, gunakan port number default 389
Maka kita langsung memperoleh hasilnya
USN digunakan untuk mengidentifikasi secara unik tiap update yang terjadi dalam naming context pada domain controller terntentu apapun tipe updatenya. Jadi sangatlah mustahil jika terdapat USN yang sama merepresentasikan perubahan yang sama pada dua domain controller yang berbeda. Ini artinya kita dapat melakukan request tiap perubahan berdasarkan USN tertentu dari domain controller yang tertentu ***, tapi tidak dimungkinkan melakukan perbandingan direktori antar DC berdasarkan nilai USN yang sama. Perubahan description untuk komputer Mr John Doe pada computer account bernama Client001 bisa jadi berupa USN 2900 pada suatu domain controller, tapi bisa berupa USN 340012 dan USN 54003232 pada dua domain controller lainnya.
Ok, sekian dulu dan semoga bermanfaat…
Judul artikel ini sesuai dengan judul yang ada pada KB977944 di http://support.microsoft.com/kb/977944
Seting Wallpaper secara roaming mandatory melalui GPO yang secara umum kita ketahui melalui User Configuration>Administrative Templates>Desktop/Desktop>Desktop Wallpaper seperti pada gambar berikut:
Namun terdapat keharusan untuk menjalankan Knowledge Base 977944 khusus bagi Windows Server 2008 R2 dan Windows 7 agar desktop wallpaper yang diinginkan benar-benar tampil dilayar monitor.
Kita cukup memilih berdasarkan platform yang kita gunakan, dengan disertai isian email yang nantinya berisi link untuk mengunduh serta password untuk melakukan ekstrak kompresi file-nya.
Setelah selesai diupdate dengan KB tersebut diatas, maka wallpaper yang diinginkan akan muncul setelah direstart.
Rekan-rekan, sekedar melengkapi tulisan sebelumnya di sini dan juga di sini tulisan ala kadarnya berikut tentang Schema Naming Context.
Schema Naming Context (NC) pada dasarnya berisi objek-objek yang merepresentasikan kelas-kelas (classes) dan atribut(attributes) yang didukung oleh Active Directory. Schema didefinisikan pada basis forest-wide, sehingga Schema NC direplikasikan ke setiap domain controller dalam forest. Perlu diingat kembali bahwa Schema NC bersifat writeable hanya pada domain controller yang menyimpan schema master FSMO role. Root dari Schema NC dapat ditemukan dalam Schema container, yang merupakan sub-container dari Configuration container. Sebagai contoh, dalam forest wireline.com, Schema NC akan ditempatkan pada cn=schema,cn=configuration,dc=wireline,dc=com.
Walaupun container Schema terlihat seperti sebagai child dari container Configuration, namun pada dasarnya merupakan naming context yang terpisah dan berdiri sendiri. Gambar berikut menunjukkan bagaimana Schema dan Configuration NC disegregasi dalam tool ADSI Edit.
Tidak seperti Domain dan Configuration NC, Schema NC tidak memiliki dan memelihara struktur dari container atau organizational unit, tapi hanya berupa single container yang memiliki objek-objek classSchema, attributeSchema, dan subSchema. Objek classSchema mendefinisikan tipe-tipe dari kelas yang berbeda dan atribut-atribut yang terasosiasi dengannya. Objek attributeSchema mendefinisikan semua atribut yang digunakan sebagai bagian dari definisi classSchema. Terdapat juga instance tunggal subSchema yang merepresentasikan schema yang abstrak sebagai mana didefinisikan dalam LDAPv3 RFC (http://www.ietf.org/rfc/rfc2254.txt).
Demikian semoga bermanfaat…..
Tiap domain Active Directory memiliki satu Domain Naming Context (NC), yang berisi data yang spesifik domain. Root dari NC ini direpresentasikan oleh domain distinguished name (DN) dan secara tipikal direferensikan sebagai NC head. Sebagai contoh, DN dari domain wireline.com akan menjadi dc=wireline,dc=com. Tiap domain controller dalam domain mereplikasikan copy/salinan dari Domain NC.
Terlihat pada tabel berikut berisi daftar dari top level container yang default dalam suatu Domain NC. Jangan lupa untuk mengaktifkan Advanced Features dari menu View dalam Active Directory User & Computers. Alternatif lainnya, kita dapat lakukan browsing ke seluruh container ini dengan ldp.exe atau ADSI Tool.
Untuk memulai, klik Run> Adsiedit.msc
Tabel Default top-level containers dari suatu Domain NC
| Relative distinguished name | Deskripsi |
| cn=Builtin | Container untuk predefined built-in local security groups. Sebagai contoh: Administrators, Domain Users, dan Account Operators. |
| cn=Computers | Default container untuk computer objects yang merupakan member servers dan workstations. Kita dapat mengubah default container yang digunakan di Windows Server 2003/2008/2008 R2 dengan redircmp.exe utility. |
| ou=Domain Controllers | Default organizational unit untuk computer objects yang merupakan domain controllers. |
| cn=ForeignSecurityPrincipals | Container untuk placeholder objects yang merepresentasikan anggota dari group-group di dalam suatu domain yang berasal dari domain external ke forest tersebut. |
| cn=LostandFound | Container untuk orphaned objects. Orphaned objects adalah objek-objek yang dibuat dalam suatu container yang dihapus dari domain controller lainnya dalam periode replikasi yang sama. |
| cn=NTDS Quotas | Container untuk menyimpan store quota objects, yang digunakan untuk membatasi jumlah dari objek-objek yang dapat dibuat oleh security principal dalam partition atau container. Container ini baru dikenal sejak Windows Server 2003. |
| cn=Program Data | Container untuk applications untuk menyimpan data. Container ini juga baru dikenal sejak Windows Server 2003. |
| cn=System | Container untukmiscellaneous domain configuration objects. Sebagai contoh trust objects, DNS objects, dan group policy objects. |
| cn=Users | Default container untuk user dan group objects. Kita dapat mengubah default container yang digunakan dalam Windows Server 2003/2008/2008 R2 dengan redirusr.exe utility. |
Application partitions merupakan fitur yang diperkenalkan ke Active Directory sejak Windows Server 2003. Application partitions memungkinkan administrator untuk membuat area dalam Active Directory untuk menyimpan data pada domain controller tertentu yang mereka pilih, bukan pada semua domain controller di domain atau forest. Kita dapat mendefinisikan domain controller mana yang menyimpan copy dari tiap application partitions, yang biasa disebut sebagai replica. Tidak ada batasan berbasis domain atau site membership, yang artinya kita dapat mengkonfigurasi berbagai domain controller yang running Windows Server 2003/2008/2008R2 dalam suatu forest untuk menyimpan replica dari application partition. Site topology yang ada akan digunakan untuk secara otomatis membuat koneksi objek yang diperlukan untuk replikasi di antara server-server yang menyimpan replica dari application partition. Domain controller juga akan meregistrasi Service Location (SRV) records yang diperlukan, sehingga client dapat menggunakan DC locator process untuk menemukan domain controller yang optimal untuk application partitions.
Terdapat sejumlah keterbatasan yang perlu diketahui terkait dengan application partitions:
-
Application patitions tidak dapat berisi security principals, yang secara umum berupa objek tertentu misalkan user, inetOgPerson, goup dan computer object. Berbagai tipe objek dapat dibuat dalam application partition.
-
Tidak ada satupun objek yang berada dalam application partitions yang direplikasikan ke global catalog. Walaupun jika sebuah domain controller yang menyimpan replica dari application partition juga merupakan global catalog server, domain controller ini tidak akan mengembalikan objek dari application partition selama proses pencarian oleh global catalog berlangsung.
-
Objek-objek dalam application partitions tidak dapat dipindahkan ke luar dari partisinya. Hal ini berbeda dari objek-objek yang berada dalam domain, yang dapat dipindahkan antar domain.
-
Domain Naming FSMO harus berada pada domain controller running Windows Server 2003 (atau yang lebih baru, spt Windows Server 2008 / 2008 R2) untuk membuat application partition. Setelah application partition dibuat, kita dapat memindahkan Domain Naming FSMO kembali ke domain controller Windows 2000 (jika memang diperlukan seperti itu).
Application partitions diberi nama seperti halnya ke domain, sebagai contoh, jika kita membuat application partitions diberi nama “app1” di bawah domain wireline.com, maka nama DNS akan menjadi app1.wireline.com dan distinguished name akan menjadi dc=app1,dc=wireline,dc=com.
Contoh tahapan membuatnya:
Pada contoh berikut kita akan membuat application partitions pada domain wireline.com yang diberi nama App1. Pada contoh berikut domain berada pada Windows Server 2008 R2 functional level.
Dari command prompt, jalankan ntdsutil, kemudian jalankan perintah activate instance ntds dan kemudian ketikkan perintah partition management, dilanjutkan dengan melakukan koneksi ke server dengan menggunakan perintah connect to.
Masuk ke partition management mode dengan mengetikkan quit pada partition management mode seperti pada gambar di atas.
Masukkan distinguished name dari application partition dan sebuah server untuk membuat partisi :
create nc dc=App1,dc=wireline,dc=com w2k8svrdc01.wireline.com
Dalam gambar sbb:
Untuk melihat partisi apa saja yang telah ada dalam server ini, kita gunakan perintah List pada partition management mode, seperti dalam gambar berikut:
Semoga bermanfaat…
Rekan-rekan, seperti yang kita ketahui bersama, terdapat aktivitas segregasi data ke dalam partisi-partisi (partitions) pada distribusi di Active Directory secara natural. Jika data partitions tidak digunakan, maka tiap domain controller harus mereplikasikan seluruh data dalam forest. Kita dapat anggap sebuah domain adalah data partition yang besar (yang biasa disebut sebagai naming context (NC)). Hanya domain controller yang authoritative untuk suatu domain yang perlu untuk mereplikasikan seluruh informasi dalam domain tersebut. Informasi tentang domain yang berbeda jelas tidak diperlukan bagi domain controller tersebut. Di sisi lain, terdapat beberapa data Active Directory yang harus direplikasikan ke seluruh domain controller dalam suatu forest. Terdapat 2 pradefinisi naming context dalam Active Directory:
· Domain Naming Context untuk tiap domain
· Configuration Naming Context untuk forest
· Schema Naming untuk forest tersebut
Tiap-tiap dari naming context (NC) merepresentasikan tipe yang berbeda dari data Active Directory. Konfigurasi NC menyimpan data yang terkait dengan konfigurasi dari forest (atau forest wide applications), seperti objek-objek yang merepresentasikan naming context, LDAP Policies, Site, subnet, Microsoft Exchange, dan seterusnya. Schema NC berisi sekumpulan atas kelas-kelas objek dan definisi atribut untuk tipe data yang dapat disimpan dalam Active Directory. Tiap domain dalam forest juga memiliki sebuah Domain NC, yang berisi data spesifik untuk domain, sebagai contoh : user, group, komputer, dll.
Dalam Windows Server 2003 Active Directory, Microsoft memperluas konsep NC dengan menyediakan user-defined partitions yang disebut sebagai application partitions. Application partitions dapat berisi berbagai tipe objek kecuali security principals. Manfaat yang paling nyata dari hal ini adalah administrator dapat mendefinisikan domain controller mana saja yang mereplikasikan data yang berada dalam partisi-partisi ini. Application partition tidak dibatasi oleh domain boundaries, seperti pada Domain NC, mereka dapat tetap eksis pada domain controller yang running Windows Server 2003 atau 2008/2008 R2 dalam suatu forest, tidak peduli domain mana yang memiliki DC tersebut.
Kita dapat melakukan retrieval daftar dari naming context dan application partitions dari domain controller yang memaintenance-nya secara spesifik dengan melalukan query RootDSE entry. Kita dapat melihat atribut RootDSE dengan membuka utiliti Ldp, yang tersedia sebagai bagian dari Windows Support Tools (Windows Server 2003) dan telah tersedia dalam Windows Server 2008/2008R2.
Gambar Eksekusi ldp.exe melalui menu Run di Windows Server 2008.
Gambar Tampilan Ldp RootDSE output dari domain controller Windows Server 2008
Kita dapat melihat Distinguished Name (DN) dari root domain dalam forest ini (DC=W2K8SVR01, DC=Wireline, DC=COM), dan DN dari application partition yang terdapat dalam domain controller ini (seperti DC=DomainDnsZones,DC=wireline,DC=com) dan seterusnya.
Informasi ini amat penting dan berguna saat menuliskan script dan program yang meng-query Active Directory. Dengan me-utilisasi atribut DSE, kita dapat menghindari hardcoding path dalam kode-kode pemrograman.
Ok, semoga bermanfaat…