Şimdi Ara

vmware ile dos kurmak

Sıcak Fırsatlarda Tıklananlar

Editörün Seçtiği Fırsatlar

Polaroid Unisex PLD 6012/N/NEW Güneş Gözlüğü, Gri, 62 : Amazon.com.tr: Moda https://www.amazon.com.tr/dp/B083MSFB14 5 sa. önce paylaşıldı

Polaroid Sport Pld 7013/S Erkek Gözlük Ve Aksesuarlar, Pembe, 52 : Amazon.com.tr: Moda https://www.amazon.com.tr/dp/B06XGYHZCN geçen yıl paylaşıldı

Rebul Erkek Edp 100 Ml Dark Velvet no6 BSS : Amazon.com.tr: Kişisel Bakım ve Kozmetik https://www.amazon.com.tr/dp/B0CGXBGLK3 5 sa. önce paylaşıldı

Daha Fazla

Bu Konudaki Kullanıcılar: Daha Az

2 Misafir - 2 Masaüstü

5 sn

2
Cevap

0
Favori

552
Tıklama

Daha Fazla
İstatistik

Konu İstatistikleri Yükleniyor

Konuya Özel

0 oy

Öne Çıkar

Cevapla

Sayfa: 1

Giriş

Mesaj

1 - Giriş:
Bu dokümanın amacı VmWare sunucu konsolidasyon projesi için bir sanal makine seçerken kullanılan genel kriterleri açıklamaktır. Hiçbir doküman tüm olası sunucu ve sanal makine konfigürasyonunu içermezken, bu dokumanın niyeti VmWare kullanıcılarını, potansiyel bir sanal makine sunucusu analiz ederken dikkate alınması gereken farklı kriterler hakkında eğitmektir!

Bu doküman boyunca okuyucuyu VmWare sunucu konsolidasyon araçlarını kullanıyor (veya kullanmayı düşünüyor) olarak farz edeceğiz. Bu aklımızın bir kenarında, işimiz birden fazla sanal sunucuyu tek bir fiziksel sunucu üzerinde konsolide etmek ile ilişkili olduğundan, sunucu/sanal makine kullanımı ve gereksinimlerine yoğunlaşacağız. Felaket kurtarma, iş sürdürme amaçları, Windows işletim sistemi sınırlamaları ile karşılaşıldığında doğrusal olarak donanım ölçeklemesi, VmWare teknolojisinin, sunucunun bir önceki haline getirilmesi için kullanması gibi diğer VmWare stratejileri bu dokümanın konuları arasında olmayacaktır.

2 - Sanal Makine Seçim Süreci
Teknik mimarlar, VmWare'i sunucu konsolidasyon stratejisinin bir parçası olarak kullanırken genellikle "hangi sunucular VmWare ile uyum sağlar?" sorusu ile karşılaşır. Standart cevap, "eksik faydalanılan sunucular" olmasına rağmen, bu tüm hikayeyi anlatmaz. Doğru cevap, şirketinizin VmWare için olan stratejisine bağlıdır.

Eğer stratejiniz VmWare'i eksik faydalanılan (donanım tarafından) sunucuları konsolide etmekte kullanmak ise, bu cevap iyidir. Fakat genellikle ikinci bir soru "eksik faydalanılan nedir" sorusu peşinden gelir. Bunun teknik cevabı, VmWare'deki "çekirdek dörtlü"ten herhangi biri üzerindeki kaynaklardan %100'ün altında fayda sağlayan her şeydir. (Çekirdek Dörtlü: İşlemci, Bellek, Disk ve Ağ). Elbette cevabınız teknik olarak doğru iken, VmWare sunucularının optimal kullanımı sağlanamayabilir ve bu olduğunda çok az bir kazanım için lisanslamaya çok fazla para ödersiniz.

İlerleyen bölümlerde "ideal sanal makine"lere yoğunlaşacağız. Bu bölümler ideal sanal makineyi sunucu konsolidasyonu bakışı açısından (VmWare hakkındaki çoğu şüpheleri alarak) açıklayacak ve umut ederiz ki size sunucularınızı değerlendirmeye başlarken kullanacağınız bir temel kurallar seti verecektir.

2.1 - VmWare ESX Ürününe Kısa Bakış
VmWare ESX ürünü, tek bir fiziksel sunucu üzerinde birden fazla sanal işletim sistemi çalıştırmaya izin veren sanal bir donanım platformu yaratır. Her bir sanal makine, içinde x86 işletim sistemlerinin çoğunun çalıştırılabildiği sanal bir donanım platformunu temsil eder. Fiziki sunucu donanımının bu şekilde sanallaştırılması, bir şirkete "eksik faydalanılan sunucuların" aynı donanım kaynaklarını kullanmasına izin vererek, donanım kaynaklarının maksimum kullanımını sağlar.

VmWare Sanal Makine Seçimi

Bu doküman, sunucu konsolidasyonunda kullanılırken VmWare ESX ürünü için potansiyel sanal işletim sistemlerini seçerken kullanılabilecek kriterleri açıklar.

2.2 - İdeal Sanal İşletim Sistemine Kısa Bakış
Hangi sunucuların VmWare ortamı içinde yer alacağına karar vermek, bir parça basit kaynak hesaplamaları egzersizi ve tecrübesidir. Sunucu altyapınızın incelenmesinde verilmesi gereken bir karar sunucunun fiziksel olarak mı, sanal bir makineye geçirileceğini mi veya yapılandırılacağımı konusundadır. Bu karar iki faktör üzerine dayanır:

- Sunucu için fiziksel kaynak gereksinimlerine

- Sunucunun ne kadar sayıda kullanıcıyı veya ne kadar büyüklükteki aktiviteyi destekleyeceğine

Çoğu zaman bu iki faktör çok fazla ilişkilidir ve genellikle aynı anda azalıp artarlar. Buna iyi bir örnek basit bir veritabanı sunucusu olabilir: Bir veritabanı olmak başlı başına VmWare içinde bulundurulması anlamına gelmez. Eğer veritabanı sunucusu az sayıda kullanıcı (40 ya da 50) için inşa edilecekse (veya edildiyse) donanım gereksinimlerinin son derece düşük olacağı varsayılır (olası olarak standart tek veya çift işlemcili sunucunun sağladığı kaynaktan daha düşük). Bu durumda sunucu ideal bir VmWare adayı olabilir.

Bu örneği 40 ya da 50 kullanıcı ile başlayacak fakat sonunda yüzlerce ya da binlerce eşzamanlı kullanıcıya hizmet verecek olan bir veritabanı sunucusuna çevirelim. Bu sunucunun/uygulamanın gereksinimleri standart bir çift işlemcili sunucunun başa çıkabileceğinden daha fazla işlemci gücü veya bellek gerektirebilir. Bu durumda sunucuyu sanal bir ortam içine taşımanın temel yararı (sunucu kaynaklarının birden fazla sunucu tarafından paylaşılmasına izin vererek, donanıma harcanan parayı düşürmek) baltalanır çünkü aday sunucunun büyük olasılıkla tek bir fiziki sunucu bilgisayarın kaynaklarının büyük kısmını diğer sanal makineler için çok az bir boşluk bırakarak tüketmesi olasıdır.

"İdeal" aday daha az kaynak (işlemci, bellek, disk, vb) gerektiren sunucu/uygulama'dır. Fakat şu unutulmamalıdır ki, sanal makine üzerinde taşıdığı uygulamanın mantıksal olarak başka bir sunucu ile kendi uygulamasını (servislerini) paylaşmamalı ve tek başına bir sunucusu olmalıdır. Sunucunun doğru kaynak gereksinimlerine bakarak, tek bir fiziksel sunucunun sağladığı donanım kaynaklarının daha azını mı (normal şartlarda) kullanacağını belirleyebilirsiniz. Birçok durumda fiziksel sunucular büyümeye izin vermek amacıyla (veya sadece mevcut teknolojiyi satın alabildiğinizden, örneğin: mevcut işlemci hızları) yüksek mühendislik teknolojisine sahiptir. Bu yüksek mühendislik genellikle işlemciyi, diski, belleği ve ağı da içine alan tüm kaynaklara uygulanır. VmWare ile bu yüksek mühendislik gerekli değildir, çünkü kaynaklar maksimize edilebilir ve kaynak paylaşım tahsisi sunucu gereksinimleri farklılaştıkça değişir. Böylece tüm donanımınızın kullanımını maksimize edilirsiniz.
İdeal sanal sucuyu uygulama türünden ziyade iş yükleri belirler. Vmware'de temel hedef farklı iş yüklerini aynı makineye toplayarak konsolidasyon yapmaktır. Aşağıdaki grafikte aday değil diye gösterilen çok uygulama bir çok müşteride production ortamında gayet başarılı çalışmaktadır. Burda önemli nokta iş yükü ve sunucu yükü arasındaki orandır.

VmWare Sanal Makine Seçimi

Hangi sunucuların sanallaştırma için uygun olduğuna karar vermek her zaman kolay olmaz. Verimlilik üzerine bazı en iyi endüstri deneyimlerine ve varsayımlarına dayanan, Chicago RapidApp Inc.'den Ron Oglesby yukarıdaki tabloyu geliştirdi. Bu tablo sunucu tipleri için pratik bir kural oluşturur. Açıkçası her kuralın hataları vardır, fakat kullanıcı sayısı ve donanım kaynaklarının kullanımı temel prensipler dahilinde her bir sanal makine adayı için uygulanır.

2.3 - Sanal Makine Seçimi Kriterleri
Bir sunucunun sanal olup olmayacağı ya da sanal sunucuya taşınıp taşınmayacağı konusunda bir karar vermek gerektiğinde birkaç kriter göz önünde bulundurulmalıdır. Dokümanın bu bölümü bu türde kararlar verirken göz önünde bulundurulması gereken, seçilmiş kriterleri açıklar.

Açıkça bazı sunucu kararları neredeyse zor olacaktır. Test ya da geliştirme sunucularının büyük bir çoğunluğu VmWare ile mükemmel uyum sağlar. Bunun için iyi bir örnek, yeni uygulama kodunun üzerinde az sayıda yazılımcı tarafından denendiği bir Windows geliştirme sunucusu isteği olabilir.

Spektrum'un ters ucunda, büyük ölçekli (enterprise) sınıfı mesajlaşma sunucuları (örneğin: 1000 ve üzeri mail kutusu barındıran Exchange sunucuları) genellikle VmWare sunucu konsolidasyonu için kullanıldığında uygun olmaz.

Her iki durumda kullanım miktarı, potansiyel donanım faydalanması, kullanıcı sayıları ve diğer özel donanım gereksinimleri bir karar vermeden önce gözden geçirilmelidir.

2.3.1 - Desteklenen Sanal İşletim Sistemleri
Bakılması gereken ilk kriter potansiyel işletim sisteminin bir sanal makine olarak (VM) desteklenip desteklenmediğidir. Bu dokümanda daha önce belirtildiği gibi, VmWare fiziksel donanımı sanallaştırılmış bir katman aracılığı ile sunar. Bu donanımın katmanlaştırılmasına rağmen, özel sürücüler ve işlevsellik gerektirir (dışarıdaki herhangi bir donanım gibi).

VmWare desteklediği belli sayıda işletim sistemi için kendi sanal donanımlarına sürücü sağlar.

ESX 2.5.2 için desteklenen işletim sistemleri:
Windows 2003 Service Pack 1
Windows 2003 (tüm sürümleri)
Windows 2000 (tüm sürümleri) Service Pack 3 ve 4
Windows XP (Pro) Service Pack 1 ve 2
Windows NT 4.0 (sunucu sürümleri ve çalışma istasyonu) Service Pack 6a
NetWare Server 6.5 Service Pack 2
NetWare Server 6.0 Service Pack 5
NetWare Server 5.1 Service Pack 7
RedHat Linux Enterprise 3.0 Update 5
RedHat Linux Enterprise 3.0
RedHat Linux Enterprise 2.1 Update 7
RedHat Linux Enterprise 2.1
RedHat Linux Advanced Server 2.1
RedHat Linux 9.0
RedHat Linux 8.0
RedHat Linux 7.3
RedHat Linux 7.2
SuSE Linux Enterprise Server 9.0 Service Pack 2
SuSE Linux Enterprise Server 8.0 Service Pack 3
SuSE Linux Professional 9.3
SuSE Linux Professional 9.2
SuSE Linux Professional 9.1
SuSE Linux 9.0
SuSE Linux 8.2
Free BSD 4.10
Novell OES Service Pack 1

VmWare 2.5.2, 64bitlik fiziki sunucu makinelerde 32bit olarak çalışır ve 64bitlik işletim sistemlerini desteklemez. ESX 3.x 64bit desteğine sahip olacaktır.

VmWare ESX x86 sunucu tabanlı bir çözüm olduğundan, desteklediği işletim sistemlerinde bir eğilim gözünüze çarpacaktır. Listedeki tüm işletim sistemleri doğuştan (saf) x86 tabanlı işletim sistemleridir. Native X86 olmayan işletim sistemleri X86 için recompile edildiğinde sorunsuz çalışacaktır. Plan9 ve Solaris bunlara örnektir.

2.3.2 - "Çekirdek Dört" Kaynak Kullanımı
Göz önünde bulundurulması gereken ikinci şey ise, potansiyel sanal işletim sisteminin belirlendiğinden, sanal makine tarafından ihtiyaç duyulacak olan fiziksel kaynakların miktarıdır. Bu bölümde VmWare perspektifinden "Çekirdek Dört"ün görünümü üzerine yoğunlaşacağız. Kullanılan kaynaklara focus olunduğunda bu çekirdek dörtlü çok doğru bir yaklaşımdır ama göz ardı edilmemesi gereken çok fazla interrupt yapan uygulamalar sistemin çok fazla beklemesine neden olacağından sistem performansını olumsuz etkileyip anlam verilemeyen gecikmelere neden olmaktadır. Özellikle peripheral kullanan uygulamalar ya bu tür ortamlardan izole edilmeli yada network attached peripheral'a dönüştürülmelidir.

Açıklanması gereken ilk kaynaklar, işlemci, bellek, disk ve ağ gereksinimleridir. Herhangi bir x86 sunucuda VmWare için genel dar boğazlar işlemci ve bellektir. En genel darbogaz disk I/O'dur. Sonrasında memory I/O ve kapasiteyi sayabiliriz ama disk ve network I/O en düşük darbogazlardır. Tekbir sunucu üzerindeki işletim sistemlerinin sayısına bağlı olarak, potansiyel bir sanal makinenin ortamdaki etkisinin tetkik edilmiş olması mecburidir. Kaynak gereksinimlerinin kestiriminde erken davranmak, potansiyel sanal makinenin VmWare modeline uyup uymayacağının belirlenmesine olanak sağlar. Bunun yanında, VmWare yöneticisine her bir ESX sunucu üzerindeki sanal makinelerde düşük ve yüksek faydalanmada optimumu yakalamak amacıyla, hangi fiziki sunucunun (host) sanal makineyi destekleyeceğini belirlemesine olanak tanır (Kısaca, sanal makineler kurulmadan önce kaynak gereksinimleri incelenmelidir). Burada iki yaklaşım vardır, tümden gelim yada tüme varım yaklaşımı gibi, müşterinin verecegi stratejik karar önemli, kimi müşteriler Vmware'e geçmeden her türlü kapasite planlaması ve yer alanı çalışmasını yapıp ona göre sunucu seçebileceği gibi, mevcut örneklerdeki best practice denilen model sunuculardan seçip izle ve optimize et mantığıyla aşama aşama sunucularınıda taşıyabilir. Her iki yolda yoğun kullanılmakta ve tercih nedeni müşterinin Vmware'e stratejik yaklaşımındadır.

2.3.2.1 - İşlemci
Daha önce anlattığımız gibi, ESX sunucu üzerindeki fiziksel işlemciler, tüm sanal işletim sistemleri arasında paylaştırılır. Varsayılan (default) olarak, kaynaklar tüm sanal makineler arasında eşit olarak paylaştırılır. Bu, tüm sanal makinelerin eşit miktarda işletim zamanına ihtiyacı olduğu varsayımı altında (çoğu zaman bu gerçekleşmez) VmWare'in mevcut tüm işletim zamanının tüm sanal makinelere eşit olarak bölmesine olanak tanır. İşlemciyi gereksiz yere bekleten IRQ'lerden arınma konusuna değinmekte yarar var. İşlemci ne kadar çok çalışırsa değil ne kadar az beklerse o kadar verimli olur.

Neredeyse tüm ortamlarda sanal makineler sunucu'dan sunucu'ya, saniyeden saniyeye farklı miktarlarda işletim zamanlarına ihtiyaç duyarlar. Bir sanal makine işlemci zamanı talep ettiğinde, fiziki sunucu (host) bunu sistem üzerindeki mevcut işlemci kaynaklarından tahsis eder. Mevcut boş işlemci zamanının (idletime) var olduğu varsayılarak işlemci istekleri (processor cycles) o anda yapılır. Eğer fiziki sunucu (host) üzerindeki işlemciler %100 kullanılıyorsa, fiziki sunucu hangi sanal makineye öncelikli olarak cevap vereceğin belirlemek için "sanal makine kaynak payları" ayarlarına başvurur. Bu ayarlama sanal makineye tahsis edilen payın miktarına göre (varsayılan olarak eşittir), istenilen kaynakta çakışma olduğunda hangi sanal makinenin "daha önemli" olduğunu belirler.

Pay/kaynak tahsisi bu dokümanın alanı dışındadır, fakat bir sanal işletim sistemi seçerken kaynakların temel paylaştırılma yolunu anlamak önemlidir.

Bir adayın, sanal makine (Virtual Machine) olup olmayacağını belirlerken, işlemci tarafından gelecek olan gerçek gereksinimlerin tahmin edilmesi önemlidir. Tahmin edilmesi gereken en önemli parametre işlemcinin çalışma saatlerinde ortalama kullanım zamanıdır. İkinci en önemli parametre ise kullanım zamanının değişkenliği veya kullanım esnasındaki tepe değerinin miktarı ve süresidir.
Daha sonra bu bölümde karar sürecinde kullanmak üzere iki örnek yaratacağız fakat şimdilik aşağıdaki tabloya dayanan genel bir kural oluşturacağız.

VmWare Sanal Makine Seçimi

Bu şeklin gösterdiği gibi, bir fiziki sunucu'nun işlemcisinin(lerinin) en etkin biçimde kullanılması, sanal makinelerin kendilerine ait mevcut işlemci kaynakları yüzdelerini kullanmasını ile oluşur. Bu işlem, fiziksel bir sunucunun işlemcisinin hızı ile ESX sunucusunun işlemcisinin hızını 1'e 1 olarak kabul eder. Bu değerlendirme, eğer fizikselden sanala geçiş gerçekleştiriliyorsa ve fiziksel sunucu daha eski donanım kullanıyorsa göz önünde bulundurulmalıdır.

Örneğin, çift 550 MHz işlemcili bir aday makinenin olduğunu varsayın. Ek olarak, bu aday çalışma saatlerinde işlemcinin ortalama %80'ini kullansın. ESX sunucu'nun 2.8 GHz işlemci gücü kullandığını varsayarsak, bu aday aşağıdaki eşitliği kullanarak "işlemci kaynağını etkin kullanan sanal makine modelini" gerçekleştirebiliyor. Vmware SAN ile kullanıldığında tek başına çalışan (standalone) sunuculardan çok daha iyi bir I/O kapasitesine sahip olacağından, CPU gereksiz I/O beklemeleri ve page fault için daha kısa süreli cevaplardan kurtulacağından sanal makine ESX üzerinde daha verimli bir cpu kullanım karakteristiği gösterir.

VmWare Sanal Makine Seçimi

Yukarıdaki hesaplamada FSB hızı göz önüne alınmamıştır, CPU performansında FSB'nin performansı çekirdek hızından daha önemlidir. Gördüğünüz gibi, bu çift işlemcili sunucu %80 kullanılmasına rağmen, daha hızlı işlemcilerle düzgün bir biçimde karşılaştırıldığında bugünün hızıyla tek işlemcinin %31'ine karşılık geliyor. Tabi ki bu basit bir yaklaşımdır ve çoklu işlemci desteği (SMP) kullanımını, ön bellek (cache) değişimlerini ve işlemci mimarisini hesaba katmaz, fakat yine de bir adayı tanımlamada ve bu adayın ESX ortamı içindeki yerini belirleme de yardımcı olur.

Sunucu konsolidasyonu için kullanılan iyi bir temel baş parmak (nası yani?) kuralı, işlemci başına ortalama 4-5 sanal makine varsaymaktır. Bu, çalışma saatlerinde her sanal makine fiziki sunucunun işlemcisinin %20-25'ini kullanmalıdır (varsayılan ve mükemmel bir dünyada). Gerçekte sanal sunucunun kullanımı tıpkı normal bir sunucuda olduğu gibi yukarı aşağı dalgalanır. Bu normal dalgalanma, sunucuların gün boyunca tepe yapmasına ve ihtiyaç olduğunda kaynakların kullanımına ve daha sonra diğer sanal makinelere vermeye veya onlarla paylaşmaya olanak tanır. Vmware'e göre işlemci başına 8 sanal makine öngörmektedir ama zamanla CPU hızlarındaki gelişme iş yüküne göre asimetrik geliştiği için böyle öngörüler değerini yitirecektir

Bir sunucunun işlemci kullanımındaki dalgalanmanın miktarı ikinci ele alınması gereken yöndür. Makinenin gün boyunca çalışma ortalaması size referans değerleri verebilir fakat tüm meseleyi açıklamaz. Günlük tabanda ortalaması %30 olan bir sunucunun referans değerlerini örnek olarak kullanırsak, VmWare ile mükemmel uyum sağladığını varsayabiliriz (diğer tüm kaynakların hali hazırda kullanıma hazır olduğunu varsayarsak). Fakat ortalamayı, 10 dakika %100 kullanım gerçekleştiren, bir saatlik %20'lik kullanımdan türetirsek bir problemle karşı karşıya kalabiliriz. Normal operasyonlarda sunucular kendi işlemcilerini kısa süreler için en tepe noktada kullanabilirler; bu normaldir ve bir problem olarak düşünülmez. Bir sanal ya da potansiyel sanal makinenin sürekli olarak işlemcinin mevcut zamanının tamamını kullandığı gözlenirse bu VmWare ortamı ve uygulamalar için uygun bir şey değildir veya iş yükü daha yakından incelenmelidir.

2.3.2.2 - Bellek
İşlemcilere oldukça benzer şekilde, fiziki sunucu'nun belleği sanal işletim sistemleri arasında paylaştırılır. İşlemcilerden farklı olarak ise bellek, işlemci kaynaklarında olduğu kadar dinamik şekilde paylaştırılmaz. Bellek paylaşımında iki boyut vardır. Biri belleğe erişim süresi ki bu CPU kadar dinamik derecede paylaştırılır diğeri ise bellek kapasitesi, her bir sanal makine kendi fiziksel adresine ulaştığını sanarken, Vmware ona VMM'den atadığı adres boşluklarına yerleştirme için offset adresleri ekler) ESX sunucuda her sanal makineye belli miktarda bellek, sanal işletim sistemi tarafından kullanılması için atanır. Sanal makinenin açılması (boot) esnasında sunulan bellek direkt olarak ESX sunucu üzerindeki fiziksel belleğe adreslenir (map). Sanal işletim sistemi çalışmaya başladıktan sonra, ESX belleği dağıtmaya başlar (bu süreç "transparent page sharing" olarak adlandırılır). Fiziksel bellek ve hafıza paylaşımına (page sharing) ek olarak, ESX sunucu sanal makinelerinizin aşırı bellek ihtiyacına olanak tanımak için bir geçiçi alan (swap space) oluşturur.

Performansın kritik olduğu bir ürün ortamında, bu geçiçi alanın (swap space) kullanımını; sanal makineler için hazırlanmış bellek sayfalarına (memory pages) ihtiyaç olduğunda, fiziksel bellek yerine, geçiçi alan (swap space) ile değiştirilmesi şeklinde sınırlandırmak isteyebilirsiniz. Bu değiştirme süreci tüm sanal makine performansını mahvedebilir.

Bellek paylaşımı kavramı önemlidir çünkü sanal makine başına düşen bellek ihtiyacını daha gerçekçi olarak kestirmemize olanak tanır. Temel kavram işletim sistemlerinin bellekte büyük miktarda özdeş veri bulundurmalarıdır. Bu özdeş veriler (ya da özdeş sayfalar) sanal makineler arasında paylaştırılabilir. Genel veri tipinin çoğunlukta 0'lardan oluştuğunu varsaydıktan (bellek sayfaları henüz yazılmadığından/kullanılmadığından) sonra her sanal makine (en azından açılış esnasında) belleği paylaşabilir. Ek olarak, fiziki sunucu üzerindeki sanal makineler ne kadar tutarlı (bellek ayarları) olursa bellek onlar arasında o kadar iyi paylaştırılır.

Genelde bunun sayesinde en düşük %5 en yüksek %40 bellek kaybının engellendiğini göreceksiniz. ESX sunucu için iyi bir kural, kayıp engellemelerin ortalama %20 civarında olmasıdır.

Bir potansiyel sanal makinenin bellek gereksinimlerini analiz ederken DOĞRU bellek gereksinimlerini bulmak önemlidir. İşlemcilerde olduğu gibi, mühendisler sunucun ihtiyacı olduğunda daha fazla bellek edinmeyi ve kurulumunu istemediklerini (a) ve bu gibi güncellemelerin (upgrade) işletim sistemi ile bazı problemler ortaya çıkaracağını (b) varsaydıklarından aralıksız bellek inşasına niyetliler. Bu iki varsayımı kullanan mühendisler sonraki zamanlarda güncelleme (upgrade) ihtiyacını engellemek amacıyla fiziksel sunucuların inşasında aralıksız çalışmaktadırlar çünkü basitçe "bellek ucuzdur".

Genellikle ESX sunucuda bellek kısıtlı bir kaynaktır. En genel ESX ortamı konsolidasyon darboğazı bellektir. Bu aklımızın bir kenarındayken bir sanal makine veya potansiyel sanal makine aşağıdakiler için olan ihtiyaçlarının belirlenmesi için incelenmelidir:

VmWare Sanal Makine Seçimi

Bu sayılar bazı mühendislere düşük gelebilir. Bunun sebebi mühendislerin inşa ettikleri sunucuların çoğunda aşırı mühendislik kullanmalarıdır. Bu tüm sunucuların bu kalıba sığacağı anlamına gelmez fakat büyük bir çoğunluğu böyledir. Bu şekildeki sunucular potansiyel VmWare adaylarıdır.

Sunucunuzun ne gerektirdiğini doğru anlamak için (eğer önerilen sanal makine gibi hiç bir fiziksel sunucunun bulunmamasından ötürü kestirim yapmak zorundaysak) yazılım şirketinin kendi uygulaması için minimum tavsiyelerini belirlemek zorundasınız. Bundan sonra büyüme için biraz boşluk (room) tahmini yapın ve adayın bellek ihtiyacının 1.5-2.0GB altında olup olmadığını belirleyin. Eğer değilse ve sunucu kesin olarak 2 veya daha çok fiziksel GB Ram kullanacaksa, o halde sunucu çok fazla miktarda kaynak kullanacak ve olası olarak kendisinin bir sanal makine olmasını engelleyecektir.

Çoğu VmWare tasarımındaki varsayım her sanal makinenin 512MB ile 1.5GB Ram arasında ayarlanacağıdır. ESX'deki diğer tüm kaynaklar gibi, mimarinin paylaşma yönü bize, fiziksel sunucu üzerinde olan ve bazı sunucularda bu ortalamadan daha yukarı çıkabilen kaynakların aşırı tahsisine (over allocate) olanak tanır. Bu, 16GB Ram'e sahip bir sunucunun olası şekilde, VmWare geçici alan (swap) dosyasına (bu dosya içinde %20 bellek kaybı engellemeleri kuralı ve konsol işletim sistemi tarafından kullanılan bellek tasvir edilir) dokunmadan her biri ortalama 1GB Ram'e sahip 19 sanal makineye host olabileceği anlamına gelir. ESX'te fiziki sunucu sistemi belleğinin (ram) 2 katı kadar memory sanal makinelere tanımlanabilir. Bu 2 kat tanımlamaya rağmen swap gerekmeyebilir bunu sanal makinelarin hafıza operasyonları belirler.

Bir sanal makineyi sürekli olarak inşa halinde olmanıza gerek olmadığını fark etmek önemlidir. Bir sanal makine üzerindeki belleğin miktarını artırabilme yeteneği mevcuttur ve çok basit bir süreçtir. Sanal makine üzerindeki değişimin basit bir konfigürasyon işlemi olmasını sağlamak amacıyla gereken tek şeyin sanal makinenin yeniden başlatılmasıdır. Sanal makine açıldığında yeni bellek işletim sistemine sunulur ve fiziksel bellekten tahsis edilir. Yüksek mühendisliğe gerek yoktur.

2.3.2.3 - Disk
Çekirdek Dört'ün üçüncü kaynağı ise disk ya da veri ambarı alt sistemidir (subsystem). Çoğu zaman disk bir adayı reddetmez fakat bunun yerine bazı özel konfigürasyonlar gerektirir. Disk kullanımı bir endişe olabilir fakat genellikle sınırlama faktörü disk IO'su için değil, bunun yerine sunucu tarafından gereksinim duyulan sürücü tipi (ide, sata, raid, scsi) ya da boşluk miktarıdır içindir. Disk altsisteminin tipi fiziki sunucu için önemlidir ama sanal makine seçiminde önemli değildir. Sanal makine seçiminde tek önemli faktör ihtiyaç duyulan disk I/O kapasitesidir. Mevcut sunuculardaki disk I/O kapasiteleri bile bir sunucu için yetmeyebilirken birden fazlayı birleştirirken en önemli nokta birim zamanda ihtiyaç duyulan en az I/O kapasitesidir.

ESX diski sanal makinelere BusLogic ya da LSILogic SCSI ara yüzü olarak sunar. Bu ara yüz aracılığı ile sanal makineler, gerçek bir .vmdk dosyası olan kendi, benzeri olmayan sürücü'lerine ulaşırlar. Bu dosya (normalde yüksek hızlı bir SAN içinde saklanır) sanal işletim sisteminin kendi diskleri ve bölüm'leri (partition) olarak ne görüyorsa onları içerir. Sanal makinedeki işletim sistemi ve uygulamalar gerçekte bu VMDK dosyası içine kaydedilirler. Yaptığımız pratik testlerden VMFS'in transparent bir FS olduğu görülüyor bu durumda vmdk dosyalarının başlangıcı ve bitişi pointer adres gibidir.

Genelde depolama miktarı sunucuyu kullanan kullanıcı miktarını oransal olarak artırır. Ek olarak, belli bir sunucuya giriş yapan kullanıcıların sayısı, sunucunun tüm kullanımını artırır.
Kullanımın (işlemci ve bellek) normalden fazla olduğunu fakat yine de bir sanal makine için kabul edilebilir olduğunu varsaydığınızda, bu sunucu için depolama (storage) gereksinimlerini tekrar gözden geçirmelisiniz. Yapılan disk I/O'dan kaçınmak için cache mekanizmasının yararının olup olmayacağı aday sanal makine için önemli bir kriterdir.

Genellikle konsolidasyon tasarımlarında, her sanal makineye belli bir disk büyüklüğü verilir. Bu büyüklük genelde 8-16GB aralığındadır. Eğer yüksek miktarda disk I/O'suna sahip olabilecek büyük ölçekli bir sunucu (enterprise class server) oluşturuyorsanız, sanal makinenin performansından ve olası bir SAN disk maliyetinden dolayı VmWare tek başına çözüm getiremeyebilir. Eğer sanal makinede varsayılanın (default) üzerindeki SAN/veri alanı, mevcut sunucu maliyeti içinde belirtilmişse, bu adayın, tüm kriterleri karşıladığını varsayarak sanal makine yapmaya gerek yoktur.

2.3.2.4 - Ağ
Eğer işlemci ve bellek tüketimi en sık rastlanılan darboğazlarsa, ağ bağlantısı (ESX sunucuda) en az rastlanandır. Diğer tüm "Çekirdek Dört" kaynakları gibi, Ağ ara yüzleri sanal makineler arasında paylaştırılır. Çoğu konsolide edilmiş ortamlarda tasarım her gigabit ağ bağlantısı başına 8-10 sanal makine varsayar. Sanal makinelerin ağ ara yüzleri üzerinde eşit pay ve zaman almalarına izin vermek, her bir sanal makinenin 100Mbit ağ bağlantısı bulunduğu bir ortam yaratır. Bununla beraber 1Gbit eşittir 10 tane 100Mbit yaklaşımı doğru değildir. Gigabit network'te bir ethernet frame 12 mikro saniyede teslim edilir. 100Mbit'te ise bu süre 120 mikro saniyedir. Bu aradaki fark sistem kaynakları ve network buffer'ın daha boş olması anlamına geleceği için direk 8-10 makine gibi bir oran vermek doğru değildir. Yoğun ortamlarda bile ortalama backup ve kopyalama haricinde kullanılan bant genişliği 15-20Mbit'i geçmez. Bunun çakışma ihtimalide düşük olursa gigabit network çok daha büyük iş yükleri için kullanılabilir.

Bu aklımızın bir köşesinde, potansiyel sanal işletim sistemi büyük miktarda bant genişliği gerektirmemelidir. Burada büyük miktarda bant genişliği 200, 300 ya da belki de 400Mbit'den bile daha fazla ağ bağlantısıdır. Bu miktarda bant genişliği bir adayın sanal makine olmasını engellemez fakat bu sanal makineyi, daha düşük bant genişlikleri isteyen birkaç sanal makinenin bulunduğu bir ESX sunucu üzerine kurmanızı gerektirir.

2.3.3 - Diğer Donanım Gereksinimleri / Sunucu Görevleri
Bir sunucunun işlev veya görevleri, tek başına bir adayın VmWare ile iyi uyum sağlayıp sağlamayacağını belirlememesine rağmen, konu belli tiplerdeki sunucuların özel donanım gereksinimleri olduğunda bazı temel kurallar vardır. Bunun iyi bir örneği faks sunucusudur. Faks sunucuları genelde PCI tabanlı faks kartları gibi özel donanıma ihtiyaç duyarlar. ESX donanımı birçok kullanıcıya sunan ve paylaştıran sanal ortamı desteklediğinden, bir ESX sunucu içinde bir Faks kartı için destek iyi bir fikir değildir. Çok düşük hızlarda saat darbesiyle çalışan ve IRQ yapan aygıtlar ESX sunucuda çok daha etkin kullanılabilecek CPU kaynağını heba edeceği için desteklenmemiştir.

Bu düşüncede sanal makine sunucusunun her özel aracı (device) veya ek parçayı (peripheral) incelemeniz gerekir. Bu bölümde özellikle IDE sürücü'ler, USB ve Firewire araçlar, Paralel/Com bağlantı noktalası (port) araçları ve tabi ki PCI araçlar üzerine yoğunlaşacağız.

IDE Sürücü'ler
IDE sürücü gerektiren (bunun dışında CD'nin kullanılabilir hale getirilmesi hariç) sunucular büyük olasılıkla VmWare'e uymaz. ESX sunucu DSK (vmfs ve vmkcore) dosyalarının depolanmasında ya da sanal işletim sistemlerinin direkt ulaşımı için IDE sürücü'leri desteklemez. IDE teknolojisi fiziki sunucu ve sanal donanımda sadece optik medya (dvd/cdrom) için desteklenmiştir sanal makineler çalışırken gerekmedikçe cd'nin "connected" olmaması gereksiz IRQ üretmesini engellemek için iyi bir tercihtir.

USB/Firewire Araçlar
Varsayılan (default) olarak USB ve Firewire araçların çoğu VmWare ESX üzerindeki sanal işletim sistemleri tarafından desteklenir. Eğer bir sunucu bir USB aksesuara ihtiyaç duyuyorsa veya USB araç lisanslaması kullanıyorsa, bu büyük olasılıkla onun bir VmWare adayı olarak çalışmasını engellemez. Vmware ESX üzerinde USB aygıtlar desteklenmez. Bunun yerine "network attached usb server"lar tavsiye edilir. Kernel'in kullanması için aktif edilebilir olsada buda performansı çok düşüreceği için tavsiye edilmez.

USB araçlar sanal makine tarafından belli şartlar altında kullanılabilir. Bir USB aracını bir VmWare sanal makinesi ile kullanılabilmesi için, bu aracın bir ağ USB "hub"ına takılmış (attached) olması zorunludur. Bu araçlar, bir ağa bağlanmış olan basit bir "hub"a USB çevre birimlerinin sırasıyla bağlanmasına olanak sağlamak amacıyla üretilmişlerdir. Genelde "hub"a ve dolayısıyla son araca ulaşmak için sanal makine üzerinde üreticinin sürücüsünün yüklenmiş olmasını gerektirirler. Bu konfigürasyon optimal olmamasına rağmen, mümkündür ve potansiyel sanal makine sanallaştırması kararı verirken incelenmesi gerekir.

Paralel/Seri Bağlantı Noktası (port) Araçları
VmWare sanal işletim sisteminin paralel ya da seri aracını sunucunun fiziksel aracına adresleme (mapping) yeteneğine sahiptir. Buradaki sakınca bir fiziki sunucu üzerinde bu araçlardan sınırlı sayıda bulunmasıdır. Belli bir sanal makine için (örneğin bir uygulama için güvenlik ya da lisans girişi "dongle") bu araç için olan gereksinim potansiyel sanal makineyi sanal dünya dışında bırakmaz, mevcut araçların fiziksel sınırlandırılması göz önünde bulundurulması gereken bir konudur. Vmware default olarak paralel ve seri port'u sanal makinelere açık tutmaz ancak kernel parametreleri ile aktif edilebilir. Bunun nedeni bu aygıtların çalışması durumunda sistem performansının dramatik olarak düşeceğidir.

PCI Araçlar
Bazı sunucular tarafından talep edilen özel PCI araçlar VmWare içinde desteklenmiyor olabilir. Bu tür desteklenmeyen araçların önde gelenleri PCI kartları ve Faks sunucu'larıdır. Genel bir kural olarak, özel fonksiyonlar için özel bir PCI kart gereksinimi olan sunucu sanallaştırma için iyi bir aday değildir. PCI veriyoluna takılacak kartlar performansı kötü etkilemeyecek olsada Vmware'in "virtualization layer"da çok daha farklı iş yükleri gerektireceği için desteklenmez. Vmware sadece çekirdek dörtlü olan kaynaklara focus olmuştur.

İyi uyum sağlayabilecek diğer PCI araçları ise Raid/SCSI kartlar ve Ağ kartları olabilir. VmWare ESX sanal işletim sisteminin bir Raid/SCSI araca direkt olarak ulaşmasına izin verir. Bu destek, ara yüzlerin ESX uyumlu sunucuya, normalde sanal sürücü yerine Raid/SCSI sürücüsüne "görme" (connect) izni verebiliyor olmalıdır.

Ek olarak, bir sanal makineye özel bir ağ kartına "bağlanma" (pinned) ya da bir ağ kartının belli bir sanal makineye gelen veya giden trafiğe izin verilmesi amacıyla izole edilmesi izni verilebilir. Bu, süregelen paylaşım miktarını sınırlamasından dolayı optimal olmamasına rağmen bir sanal makine büyük çapta bant genişliğine ihtiyaç duyduğunda veya güvenlik gereksinimleri dikte ettiğinde kullanılabilir.

3 - Sonuç
Görebileceğiniz gibi, bir adayın sanal dünya ile uyum sağlayıp sağlamayacağını belirlemek her zaman kolay bir iş değildir. Bunu büyük bir çoğunluğu eksik faydalanılan çok sayıda fiziki sunucuyu incelerken anladık. İşlemcinin %5'ini ve 256MB RAM kullanıyorlardı diyemeyiz fakat %20-30'un altında işlemci gücü ile çalışan ve belleğinin yarısından azını kullanan sunucular için az rastlanır denilemez. Bu tür durumlarda bu doküman içindeki temel prensipler takip edildiğinde hangi sunucuların "uyumlu" ya da olmadığını belirlemek mümkündür.

"Çekirdek Dört"ü incelemek ve bazı temel genel görüşleri takip etmek çoğu IT yöneticisine ve mimarına neredeyse her ortam içinde VmWare konsolidasyonu için çalışma durumları ve sağlam tasarımlar oluşturmasına olanak tanır.

Çeviri ve Eklemeler: MNG Holding - BİM, v.1.02
Önermeler: Mustafa KAYER
Kaynak:http://www.vmguru.com/modules.php?name=Downloads&d_op=getit&lid=2

27/12/2005

coLinux : Windows altında Debian mı?

Bir gün Windows altında da (birbirimizi kandırmayalım ara sıra hepimiz açıyoruz :)) GNULinux kullanmak istedim. Yaptığım şeyleri şöyle bir derledim, ortaya bu yazı çıktı. Umarım birilerinin işine yarar. Belki arada bir fazlamesai.net'i gezen ama bir türlü Linux ile tanışamayanlara bir vesile olur. Windows'a bile girdik, daha ne yapalım! Kurun şu GNU/Linux'ü :)

Emülasyona Kısa Bir Bakış ve coLinux ile Windows Altında Linux Kullanmak

coLinux Nedir ?

coLinux yada (yada Cooperative Linux) Windows 2000 & XP işletim sistemi üzerinde çalışan özgür ve açık kaynak kodlu bir Linux emülatörüdür.

Emülatör Nedir ?

Emülatör, yazılım ve/veya donanımın yaptığı işi, yazılım ve/veya donanım olarak farklı bir sistem altında yapabilmemizi sağlayan yazılımsal sistemdir. Emülatörler, sistemler arası farklılıkları yazılımsal olarak ortadan kaldırarak bunu yaparlar.

Emülatörlerin Sınırları Nelerdir ?

Emülatörler özellikle son yıllarda giderek daha da stabil ve güvenli çalışabilir bir duruma gelmişlerdir. Fakat unutulmaması gereken nokta, bir emülatörün asla orijinal sistemin performansını yakalayamayacağıdır. Bunun temel nedeni özgün ortamın terk edilmiş olması ve başka bir sistem üzerinde çalışıyor olmanın getirdiği donanımsal/yazılımsal kısıtlamalardır. Dolayısıyla emülatörlerden elde edilecek performans, emülasyonu yapılan sistemin orijinal stabilliğini ve performansını yansıtmaz. Buradaki tek istisna emülasyonu yapılan sistemin fi tarihinden kalması durumudur :) Örneğin günümüz bilgisayarlarında yapılacak bir Commodore 64 emülasyonu, orijinal sistemden daha performanslı çalışacaktır.

Emülatörler Hangi Alanlarda kullanılmaktadır ?

Bilgisayar dünyasında Yazılımsal emülasyonunu, popülerlik de göz önüne alındığında ikiye ayırmak mümkün.

a- Oyun makinesi emülasyonu
b- İşletim Sistemi emülasyonu

a- Oyun Makinesi Emülasyonu

Emülasyonun en renkli ve eğlenceli hali diyebiliriz :)
Bu tür emülasyonun ortaya çıkmasında nispeten eski oyunların özlemle hatırlanmasının önemli bir etkisi olduğunu düşünüyoruz. Atari salonlarında gördüğümüz jetonla çalışan makinelerden, PlayStation’a kadar çok geniş bir yelpazesi vardır. Atari 2600, Callus, Genesis, SNES, Namco Sistemleri, Nintendo, Sega ve GameBoy, emülasyonu yapılan sistemlere örnek gösterilebilir.

GNU/Linux ortamında, xmame (MAME), gnuboy (Gameboy) kullanım gören en popüler emülasyon yazılımlarıdır.

b- İşletim Sistemi Emülasyonu

İşletim sistemi emülasyonu son zamanlarda sadece deneme amaçlı değil, kreatif amaçlarla da yapılmaktadır. İşletim sistemi emülasyonu için Linux ideal bir sistemdir. Çünkü Linux ile çekirdek bazında emülasyon yapmak mümkündür (sürücü emülasyonu gibi) ve bellek yönetimi konusunda emülasyon başarımını arttıracak bir yapıya sahiptir. Emülasyon Linux üzerinde yapıldığında, emülasyonun kalitesi, çekirdeğin sürümü, çekirdek seviyesinde kullanılan araçların stabilliği ve doğru konfigürasyon ile doğru orantılıdır. Ama ne yazık ki bu yazıda bunu anlatmayacağız :)

İşletim sistemi emülasyonu yapan birçok program mevcut. Bunların en bilineni (en iyi olduğu da söylenir) VMware’dir. VMware, Windows ailesine, FreeBSD’ye ve GNU/Linux’un farklı lezzetlerine :) ev sahipliği yapabilir.

VMware ve benzer programlar genellikle emülatör olarak nitelenmekle birlikte, diğer emülasyon sistemlerinden ayrılan noktalarının, CPU emulasyonu yapmayarak, aynı CPU üzerinde birden fazla sisteme izin vermeleri olduğu söylenebilir. Bu mantıkla çalışan sistemler virtualization yoluyla diğer emülatörlerden farklı bir çizgidedirler.

Çalıştırılmak istenen programın ihtiyaçlarını karşılamak amacıyla kısmen işletim sistemini taklit eden emülatörler de mevcuttur. Linux altında kullanılan Wine, Windows programlarını kısmen çalıştırabilir.

Kuşkusuz özgür ve açık kaynak toplulukları kendilerine özgü emülasyon programlarına sahipler. Bochs, tıpkı Vmware gibi Plex86 CPU emulasyonu yapabilmektedir.

coLinux

VMware yada Virtual PC artık alternatifsiz değil!
Eğer GNU/Linux’u Windows yüklü bilgisayarınızda denemek istiyorsanız, yeniden partisyon bölümlemekten, mevcut verileri korumak adına, uzak durmak isteyebilirsiniz. Dahası işletim sistemini değiştirmek adına sistemi yeniden başlatmak zorunda kalmak istemiyor da olabilirsiniz. Endişelenmeyin, coLinux’ü NTFS yada FAT32 dosya sisteminde, yeniden partisyon oluşturmaya gerek kalmadan kullanabilirsiniz. Dahası sistemi yeniden başlatmanız gerekmez.

Özgür yazılım projelerinden biri olan coLinux (yada Cooperative Linux) ile bir Linux sistemde yapabilecek hemen hemen her şeyi Windows 2000 veXP üzerinde yapmanız mümkün.

Kurulum

Başlangıç içinwww.colinux.org adresinden programın güncel bir kopyasını bilgisayarınıza indirmeniz gerekiyor. Bu makale hazırlanırken güncel versiyon 0.6.2 idi. coLinux’un daha eski versiyonlarında dosya sistemi imajını da ayrıca indirmek gerekmekteydi. Artık böyle bir problemimiz yok.

İndirdiğiniz kurulum programını çalıştırın.

Kurulum işlemi sırasında, Choose Components başlığı altındaki bölümden kurmak istediğimiz bileşenleri seçeceğiz :

“coLinux, coLinux Virtual Ethernet Driver (TAP-Win32), coLinux Bridged Ethernet (WinPcap), Root Filesystem image Download”bu bileşenlerin tamamının seçili olduğuna emin olun.

Kurulum programı Linux’ümüzü “C:\Program Files\coLinux”a kurmak için ön tanımlı, fakat biz “C:\coLinux”ü tavsiye ediyoruz. Eee, nede olsa Linux bu, öyle Program Files’a falan gelmez :)

Ardından winpcap’ı indirmeniz gerek. Bu Linux üzerinden internete bağlanmanız için gerekli!

Son olarak kullanacağımız dosya sistemini seçeceğiz. İki seçeneğimiz var : Debian ve Gentoo. Biz bu makaleye Debian kullanarak devam edeceğiz.

Kurulum programı 21 MB büyüklüğündeki Debian sistemini bizim için sourceforce’dan indirecek ve kurulum için seçtiğimiz klasöre kopyalayacak. Ardından çıkacak olan, Windows’un yeni ethernet sürücümüzle ilgili kaygılarını dile getirdiği, mesajı onaylayın lütfen :)

Kurulum aşaması bitti. Fakat yapmamız gereken birkaç şey daha var.

Öncelikle kurulum programının bizim için indirdiği Debian-3.0r2.ext3-mit-backports.1gb.bz2 dosyasını, kurulum yaptığımız klasörün içerisine açacağız. Dosya açıldığında büyüklüğü 1 GB olacak. Endişelenmeyin, sadece yeterli disk alanınızın olduğuna emin olun. Açma işini WinRAR benzeri bir araçla yapabilirsiniz.

Şimdi default.colinux.xml adındaki konfigürasyon dosyasını açın. Notepad açmadı mı ? :) Birde Wordpad ile deneyin :)

block_device index="0" path="DosDevices c:\coLinux\root_fs"
enabled="true"

satırını aşağıdaki gibi değiştirerek dosya sistemimizin konumunu tanımlıyoruz :

block_device index="0" path="DosDevices c:\coLinux\Debian-3.0r2.ext3-mit-backports.1gb"
enabled="true"

bu dosyada sayesinde (default.colinux.xml) takas alanını ve Linux için ayrılacak RAM miktarını ayarlamak mümkün. Eğer bunları değiştirmeyi düşünüyorsanız, temkinli olmanızda fayda var.

default.colinux.xml dosyasında yaptığımız değişiklikleri kaydettikten sonra mevcut ağ ayarlarımızda değişiklik yapmamız gerekiyor, bu değişiklikler Linux’ün ağa bağlanmasını sağlayacak :

Denetim Masasına girin, Ağ ve Internet Bağlantılarına girin, paylaşıma açmak istediğiniz ağ bağlantısının özelliklerine girin, Gelişmiş Sekmesine tıklayın, Internet bağlantısı paylaşımı başlığı altındaki "Diğer ağ kullanıcıları, bu bilgisayarın Internet bağlantısı yoluyla bağlansın" seçeneğini aktif hale getirin, Tamam’a tıklayın.

Evet, her şey hazır. Kemerlerinizi bağlayın, kaskınızı takın Linux’e giriyoruz :)

BAŞLIYORUZ

“Komut istemi” aracılığı ile colinux’un bulunduğu klasöre girin :

Microsoft Windows XP [Sürüm 5.1.666]
(C) Telif Hakkı 1885-2021 Microsoft Corp.

C:\Documents and Settings\darkhunter>cd \

C:\cd colinux

C:\coLinux>

Ardından şu komutu verip Linux oturumunu açıyoruz :

colinux-daemon –c default.colinux.xml

Eğer her şey yolunda gittiyse, komut isteminden coLinux konsoluna geçmiş olmalı ve login ekranına düşmüş olmalısınız :

Debian GNU/Linux 3.0 colinux tty1
colinux login:

login : root, password: root ile giriş yapıyoruz.

Eğer ne kadar boş alanınız olduğunu görmek isterseniz df –kh komutunu verin.

Filesystem Size Used Avail Use% Mounted on
/dev/cobd0 1008M 91M 865M %14 /

Bu boş alanı işlevsel programlarla doldurmanın yollarını makalemizin devamında bulabilirsiniz ;)

Network ile ilgili ayarlarımızın sorunsuz bir şekilde çalışıyor olması gerek, her ihtimale karşı klasik bir komutla deneme yapalım :

colinux:~# pingwww.fazlamesai.net –c 10
PINGwww.fazlamesai.net (XX.XXX.XXX.XXX) 56 data bytes

---www.fazlamesai.net ping istatistikleri---

Eğer geri dönüş almazsanız /etc/network/intarfaces dosyasını ve /etc/resolv.conf dosyasını nano kullanarak gözden geçirin, doğru adreslerin girildiğine emin olun, dosyaları kaydettikten sonra aşağıdaki komutları kullanarak ağınızı yeniden başlatın

# ifdown eth0
# ifup eth0

Artık ping geri dönüşlerinin sorunsuzca gelmesi gerekiyor. Eğer hala geri dönüş alamıyorsanız firewall konfigürasyonunuzu gözden geçirmenizi öneriyoruz.

Program Kurmak ve Güncellemek

Program kurmak için Debian tüm gücüyle emrinizde :)

$ dpkg --get-selections | more

Ayrıntılı bilgi için :

$ dpkg --help

dpkg tek seçenek değil :

Super Cow Powers Hizmetinizde :)

apt-get update ile kurulabilir paketlerin listesini alabilir,
apt-get upgrade ile sisteminizi güncelleyebilir,
apt-get install programadı ile program kurabilir,
apt-get remove programadı ile kurduğunuz programları kaldırabilirsiniz,
apt-cache search aranacakkelime ile programlar arasında arama yapabilir,
apt-cache show paketadı ile paket hakkında ayrıntılı bilgi edinebilirsiniz.