UHEM Sunucu Sistemlerindeki Yeni Yapılanma ve Değişen Kullanım Prosedürleri

UHeM sitesinden
Atla: kullan, ara

Ulusal Yüksek Başarımlı Hesaplama Merkezi'nde, kullanıcılardan alınan geri bildirimler ve edinilen deneyimler göz önünde tutularak donanımsal ve yazılımsal güncellemeler yapılmıştır. Güncellemeler beraberinde yapısal değişiklikler getirmiştir. Bu metnin amacı bahsi geçen güncellemeleri ve yapısal değişiklikleri UHeM kullanıcılarıyla paylaşmak ve kullanıcılarımızın UHeM sunucu sistemlerinden daha verimli yararlanmalarını sağlamaktır.

Yapılan güncellemeler temel olarak ikiye ayrılabilir:

  1. Donanım güncellemeleri; kullanıcıların hesaplama yaptıkları disk alanlarının donanımlarıyla ve performans ağı InfiniBand'te yapılan yönlendirme iyileştirmeleriyle ilgilidir.
  2. Yazılım güncellemeleri; edinilen deneyim ışığında genel olarak sistem yazılımları bazında yapılan yazılımsal güncellemeleri ve bu yazılımların kullanımıyla ilgili prosedürel güncellemeleri içermektedir.

Dokümanın devamında konuyla ilgili tüm detaylar paylaşılarak UHeM'deki yüksek başarımlı hesaplama (YBH) ortamı hakkında kullanıcılarımıza bilgi sağlanacak ve UHeM kaynaklarından elde edecekleri yarar maksimize edilmeye çalışılacaktır.

UHeM sistemlerinin kullanımı hakkında elde edilebilecek temel bilgilerin sunulduğu bu dokümanın en güncel haline UHEM Sunucu Sistemlerindeki Yeni Yapılanma ve Değişen Kullanım Prosedürleri adresinden erişebilirsiniz.

Donanım Güncellemeleri

UHeM performans ağı ve disk sistemlerinde yapılan donanım güncellemeleri kullancılarımızın hesaplama verimini arttırmak üzere yapılmıştır. Donanımsal olarak sorunlu disk donanımları 2011 yılı itibariyle en son disk teknolojilerini kullanan, güvenilir ve hızlı DDN disk sistemleriyle değiştirilmiştir. Bu sayede kullanıcıların yaşayacağı disk sistemleriyle ilgili sorunların azaltılması ve daha hızlı bir okuma/yazma (I/O) performansı elde etmeleri hedeflenmiştir. Performans ağında yapılan donanımsal güncellemeler ise bu ağdaki performansı arttırarak hem işlemciler arasındaki haberleşmeyle hem de disk işlemleriyle ilgili performansın artmasını sağlamıştır

Disk Sistemlerin Yapılan Güncellemeler

UHeM disk sistemleri HP MSA 20 tabanlı, sorunlu disk donanımları yerine DDN marka, güvenilirliği ve performansı yüksek, bu alandaki en yeni teknolojileri ön plana çıkartan SFA 10000 (SFA10K) çözümü içeren donanımlar ile değiştirilmiştir. UHeM bünyesine katılan DDN sistemlerinin getirdiği teknik yararlar şu şekilde özetlenebilir:

  • Mirror edilmiş (aynalanmış) Write-Back Cache (sorun olduğunda yazma işlemini tekrarlayan ön bellek) çözümü sayesinde her hangi bir RAID denetleyicisinde (controller) oluşacak sorun nedeniyle veri kaybı olmayacaktır.
  • RAID teknolojisinde kendine has uyguladığı aynalanmış (Mirrored) disk günlüğü (Journal) çözümü ile herhangi bir güç kaybında oluşacak veri kaybı, Write-Back Cache'in bahsi geçen bu disk günlüğü ile geriye dönük olarak oluşturulabilecektir. Aynalama sayesinde, aynı anda oluşabilecek donanım arızası ve güç kesintisinde veri kaybı yaşanmayacaktır.
  • Verilerin Metadata'sı 18 ayrı fiziksel disk'te tutularak olası metadata kayıpları engellenecektir.
  • DDN'in "SATAssure" teknolojisi sayesinde, RAID parite'leri her okuma işleminde kontrol edilerek herhangi bir parite bozukluğunda, bu pariteler özel olarak hızlıca düzeltilecektir. Bu sayede veri bütünlüğü çok sıkı bir şekilde kontrol edilmektedir.
  • Fiziksel bir disk belirli bir zamanda RAID dizisinde erişilemez olup, bu zaman sonunda tekrar erişilebilir olduğunda, bu kısa zaman aralığında erişilemez durumdaki disk'in tekrar devreye alınması, çok daha kısa sürecek şekilde sadece eksik olan parçalar belirlenip bu eksik parçaların yeniden inşa edilmesiyle az miktardaki performans düşüm zamanını mümkün olduğunca kısaltacaktır.
  • DDN SFA10000'in kullandığı donanım teknolojisi sayesinde çok yüksek miktarda yazma hızlarına (10 Gbps) ulaşmak mümkün olacaktır. Bu yazma hızı paralel okuma/yazma (I/O) yapabilen programlar için değil, sadece sequential (sıralı) I/O yapabilen programlar için geçerlidir. Paralel I/O yapabilen programlar çok daha fazlasını elde edebilmektedir.Verilerin Metadata'sı 18 ayrı fiziksel disk'te tutularak olası metadata kayıpları engellenecektir.
  • DDN'in SATAssure teknolojisi sayesinde, RAID parite'leri her okuma işleminde kontrol edilerek herhangi bir parite bozukluğunda, bu pariteler özel olarak hızlıca düzeltilecektir. Bu sayede veri bütünlüğü çok sıkı bir şekilde kontrol edilmektedir.
  • Fiziksel bir disk belirli bir zamanda RAID dizisinde erişilemez olup, bu zaman sonunda tekrar erişilebilir olduğunda, bu kısa zaman aralığında erişilemez durumdaki disk'in tekrar devreye alınması, çok daha kısa sürecek şekilde sadece eksik olan parçalar belirlenip bu eksik parçaların yeniden inşa edilmesiyle az miktardaki performans düşüm zamanını mümkün olduğunca kısaltacaktır.
  • DDN SFA10K'nin kullandığı donanım teknolojisi sayesinde çok yüksek miktarda yazma hızlarına (10 Gbps) ulaşmak mümkün olacaktır. Bu yazma hızı paralel okuma/yazma (I/O) yapabilen programlar için değil, sadece sequential (sıralı) I/O yapabilen programlar için geçerlidir. Paralel I/O yapabilen programlar çok daha fazlasını elde edebilmektedir.
Performans Ağı Güncellemeleri

UHeM InfiniBand performans ağında, yönlendirme mekanizmalarının verimli kullanımının sağlanması için, InfiniBand ağ anahtarlama cihazlarında kablolama çalışmaları yapılmıştır. Bu çalışmalarla birlikte hem sunucu sistemlerinin kendi içindeki hem de sunucu sistemleriyle yeni disk sistemleri arasındaki haberleşmenin performansı arttırılmıştır. Yapılan yeniden kablolama işleminin yanı sıra, hem sunucuların InfiniBand ağ donanımlarının hem de InfiniBand ağ anahtarlama cihazlarının firmware'leri güncellenerek donanım seviyesinde hataların önüne geçilmeye çalışılmıştır.

Yazılımsal Güncellemeler

UHeM sistem yazılımlarında yapılan güncellemeler ile bu güncellemelere bağlı kullanım prosedürlerindeki değişiklikler bu başlık altında ele alınmıştır. Metnin bu bölümü aşağıdaki alt başlıklara sahiptir:

  1. UHeM sistem kullanıcıları altyapısında gerçekleştirilen değişiklikler
  2. UHeM Dosya Sistemleri
  3. Dosya sistem yazılımlarında yapılan değişiklikler
  4. Dosya sisteminin kullanımı konusundaki değişiklikler ve kullanım politikaları
  5. LSF kuyruk ve kaynak yönetimi yazılımının kullanımına ilişkin değişiklikler

UHeM Sistem Kullanıcıları Altyapısında Gerçekleştirilen Değişiklikler

UHeM Proje Yönetim Sayfaları ve veritabanında yapılan değişiklikler

UHeM Proje Yönetim sitesi ve veritabanı altyapısı tamamen yenilenmiş olup,

  • Yeni proje başvurusunda bulunma
  • Proje yenileme başvurunda bulunma
  • Proje bapatma başvurusunda bulunma
  • Ek kullanıcı tanımlama
  • Bir proje kullanıcısının erişiminin kapatılması
  • Proje sırasında çıkan makale ve diğer görsel materyalin upload edilmesi
  • Proforma fatura talebinde bulunma
  • Kaynak tahsis ve kullanım istatistikleri

gibi bir dizi fonksiyon online olarak http://portal.uhem.itu.edu.tr/ adresindeki UHeM Proje Yönetim Sayfalarından yapılmakta ve yönetilmektedir. UHeM Proje Yönetim Sayfalarına email adresiniz, şifre ikilisi ile login olunabilmektedir. Eski portalde hesabı olan kullanıcılar veya şifrelerini unutan kullanıcılarımız "Şifremi Unuttum" linkini tıklayıp şifrelerin email adreslerine gönderilmesi talebinde bulunarak UHeM Proje Yönetim Sayfalarına login olabilirler. Bir proje ile ilgili başvuru, yenileme ve kapatma işlemleri proje yöneticisi tarafından yapılabilir, proje yönetici tarafından tanımlanmış ek kullanıcılar tarafından yapılamaz.

Kullanıcı adlarında yapılan değişiklikler

Sistem kullanıcılarını etkileyen en önemli değişikliklerden biri birden fazla projede yönetici veya kullanıcı olarak çalışıyor da olsa bir kullanıcının çalıştığı her bir farklı proje için kendisine verilen bütün "unix name"'lerinin tek bir unix name'inde konsolide edilmiş olmasıdır. Örneğin UHeM'de çalışan 6 projeye sahip bir proje yöneticisi için açılmış, 6 unix name'i tek bir unix name'ine indirgenmiştir. Kaynak kullanım raporları da bu değişikliğe uygun düzenlenmiştir.

Kuyruk tanımlarında yapılan değişiklikler

Açılan her proje için tanımlanmış <unix grubu>.q formatındaki bir kuyruğa iş gönderme uygulaması terk edilmiş olup detayları daha sonra anlatılacak olan serial, short, tesla, mid, long, smp, grad, ugrad, pgrad, pgrad_vlong, ugrad_e2, pgrad_e2, grad_e2, ege2, serial_e2 ismindeki yeni kuyruklar oluşturulmuştur. Bu kuyrukların bazıları tüm kullanıcıların kullanımına açıkken bazı kuyruklar istisna durumlar için oluşturulmuştur.

Kaynak Kullandırım Politikalarında yapılan değişiklikler

UHeM Kaynak Kullandırım politikalarına Kaynak Kullandırım Politikası sayfasından erişilebilir.

Proje süresi ve süre bitimiyle ilgili güncellemeler

UHeM'de açılan projeler 1 seneliğine açılır ve proje yöneticisinin süre bitiminden bir ay öncesinde Proje Yenileme Başvurusunda bulunması gerekmektedir. Expire olmuş projelerin iş teslim etmesi engellenir ve Proje Expire Tarihinden sonra üç (3) ay daha kullanıcı verisi muhafaza edilir. Eğer üç (3) ay içerisinde proje yenilemesi yapılmamışsa; proje verileri silinir. Gecikmiş Proje Yenileme Başvurularının değerlendirme sonuçlarının Proje Expire süresini aşması yüzünden sistem tarafından otomatik olarak Proje'nin durdurulması ile oluşan olumsuzluklardan Proje Yöneticisi sorumludur.

Proje kaynaklarının kullanım bilgileri

Kaynak kullanım istatistikleri UHeM Proje Yönetim Sayfalarından takip edilebilinir.

Kota kontrol mekanizması

RunSpace üzerinde kota kontrol'ü uygulaması terk edilmiş olup dosya yaşlandırmasına gidilmiştir. Bu konu hakkında detaylı bilgiyi ilerleyen bölüm başlıklarında bulabilirsiniz. AKDENIZ disk miktarı ve CPU zamanı kullanımında ise 2 seviyeli bir kota kontrolü uygulaması devam etmektedir. Bir projeye tahsis edilen AKDENIZ disk veya CPU zamanı miktarının aşılması durumunda o projenin kullanıcılarının iş teslim etmeleri engellenir. Bu aşamada proje yöneticisinin Portal sayfası üzerinden ek kaynak talebinde bulunup proje yenilemesi yapması gerekmektedir. 30 gün içinde proje yenilemesi yapılmayan projelerin kullanıcılarının erişimleri engellenir.

UHeM Dosya Sistemleri

UHeM'de iki farklı amaç için yüksek depolama kapasiteli ve yüksek I/O performanslı iki adet disk sistemi bulunmaktadır. Bu sistemlerden ilki kullanıcı dizinlerini üstünde barındıran AKDENIZ dosya sistemidir. Diğeri ise sadece yüksek başarımlı hesaplama amaçlı kullanılacak verilerin ve uygulamaların geçici sürelerle barındırılacağı RS (Run Space [İş Çalıştırma Alanı]) dosya sistemidir.

AKDENIZ Dosya Sistemi

Her bir kullanıcı hesabı için sisteme ilk girişte ev dizini olacak şekilde bir alan AKDENIZ adıyla tanımlanmıştır. Kapasitesi proje başvurusu (varsa kaynak artım talebi) ile proje grubu için toptan olacak şekilde belirlenmiş boyutlarla sınırlandırılmıştır. Bu dosya sistemine sadece ve sadece login sunucuları (lnode1, lnode2, lnode3, lnode4) üzerinden erişilebilir. Bu alan kullanıcılarımızın sonuçlanmış işlerini kendilerinin belirleyecekleri hiyerarşik dizin yapılarıyla güvenli olarak saklayabilecekleri bir alan olacaktır. Bu alan hesaplama düğümleri tarafından görülmediği için teslim edilecek işler çalışmadan sonlanacaktır.

RS Dosya Sistemi

Sistemde yüksek performanslı paralel I/O imkanı sağlayan bir alan RS (run space) adıyla tanımlanmıştır. RS dosya sistemine hesaplama sunucuları ve login (lnode1, lnode2, lnode3, lnode4) sunucuları tarafından erişilebilmektedir.

Dosya Sistemi Yazılımlarında Yapılan Değişiklikler

DDN disk sistemlerinin devreye alınması öncesinde AKDENIZ disk alanı için, ZFS isimli açık kaynak kodlu, yüksek güvenilirliğe sahip ancak YBH ortamlarına uygun olmayan, performansı düşük bir dosya sistem yazılımı kullanılmaktaydı. DDN donanımlarının devreye alınmasıyla birlikte, performans darboğazının ortadan kaldırılması için ev dizinlerinin bulunduğu disk alanı için açık kaynak kodlu, paralel I/O yeteneği bulunan Lustre dosya sistemi kullanılmaya başlanmıştır. AKDENIZ disk alanı için Lustre (1.8.3) dosya sistemi kullanılmaktadır. RS disk alanı için donanım değişikliği öncesinde de Lustre dosya sistem yazılımı kullanılmaktaydı. Donanım değişiklikleriyle beraber Lustre sürümü 1.6.5.1'den 1.8.3'e yükseltilmiştir. Bu sayede Lustre dosya sisteminin YBH ortamlarına kattığı yenilikler de kullanılmaya başlanacaktır. Lustre dosya sistem yazılımı hakkında giriş seviyesinde bilgi edinmek ve UHeM'deki Lustre dosya sistemlerinden en uygun performansı almak için dördüncü bölümünde yer alan açıklamalardan faydalanabilirsiniz.


Dosya Sistemi Kullanım Politikaları ve Dosya Sistemleri Kullanım Mantığında Yapılan Değişiklikler

Dosya Sistemi Kullanım Politikaları

  1. AKDENIZ dosya sisteminde kota uygulaması söz konusudur. Proje başvurusunda izin verilen kapasitenin (kotanın) aşılması halinde kullanıcının sisteme yeni iş teslim etmesi engellenecektir. Kullanıcılarımızın kota sınırını geçmemelerini ve dosya sistemlerinde gerekli düzenlemeleri yaparak (silme,sıkıştırma, vb.) sürekli bu alanı kontrol altında tutmalarını öneriyoruz.
  1. Akdeniz dosya sisteminde kota aşımı sonucu hesapların dondurulması halinde yeniden işlem yapılabilmesi için proje yetkilisi tarafından UHeM Portal'ı üzerinden proje yenileme başvurusu yapılması gerekecektir. Başvuruda kullanılan disk kaynağının o ana kadar nasıl kullanıldığı ve ek olarak talep edilen disk kaynağının ne amaçla kullanacağının açıklaması istenecektir. Başvurular UHeM'in ilgili komiteleri tarafından değerlendirilerek kullanıcı veya proje grubuna ek disk alanı tahsisatı yapılıp yapılmayacağına karar verilecektir.
  2. RS dosya sisteminde disk kotası uygulanmayacaktır. RS dosya sistemi, kullanıcıların yüksek performanslı disk işlemleri yapabilmelerini sağlamak amacıyla dizayn edildiği için, kullanıcıların verilerini uzun süreli RS dosya sistemindeki alanlarında tutmamaları gerekmektedir. Kullanıcınıların üzerinde hesaplama yapmadıkları verileri AKDENIZ dosya sistemine aktarmaları gerekmektedir. RS dosya sistemi veri güvenliği olan bir alan değildir. RS dosya sisteminin performansı disk alanı doldukça düşmektedir. RS dosya sisteminin yüksek performanslı ve sürekli kullanılabilir tutulabilmesi için aşağıda anlatılan veri yaşlandırma yöntemi uygulanacaktır:
  • Her haftanın son günü (Pazar) saat 23:59'da, son erişim zamanı 30 gün ve üstü olan dosyalar kullanıcılara haber verilmeksizin silinecektir.
  • Her haftanın son günü (Pazar) saat 23:59'da, son erişim zamanı 30 gün ve üstü olan dosyalar kullanıcılara haber verilmeksizin silinecektir.
lfs find /RS --atime +30
Son 30 gün içindeki dosyaları bulmak içinse aşağıdaki komut kullanılabilir:
lfs find /RS --atime -30
  • Eğer bir dosyanın 30 günden daha fazla süre RS'te yer alması isteniyorsa, bu durumda aşağıdaki bilgilerin verildiği bir e-posta'yı hesap@uhem.itu.edu.tr adresine göndermek durumundadırlar.
  1. Kullanıcı adı
  2. Proje grubu adı
  3. Muaf tutulacak dosya/dizinin path'i
  4. Ne kadar süreliğine muafiyet istendiği
  5. Muafiyet nedeninin detaylı açıklaması

Dosya Sistemi Kullanım Mantığında Yapılan Değişiklikler

Kullanıcı ev dizinleri mantığı değiştirilmiştir. Bu değişiklik kullanıcı yönetiminde yapılan, gerçek bir kullanıcının sahip olduğu birden fazla sistem kullanıcılarını tek bir sistem kullanıcısı olarak birleştirme işlemiyle paralel olarak gerçekleşmiştir. AKDENIZ dosya sisteminde UHeM'de hesabı bulunan her bir proje grubu için, proje grubu ismi sistem tarafından belirlenecek şekilde, proje grubu adıyla bir dizin /AKDENIZ/projects dizini altında oluşturulmuştur. Proje ana dizininin sahibi proje başvuru yapan sistem kullanıcısıdır. Proje grubunda yer alan tüm kullanıcılar için bu dizin altında bu kullanıcının sistem kullanıcı adıyla oluşturulmuş kullanıcı proje dizinleri yer alır. Proje kullanıcıları diledikleri taktirde ortak verilerini ve uygulamalarını proje ana dizini altında farklı dizinler oluşturarak bu dizinler altında tutabilirler. Kullanıcıların ev dizinleri, AKDENIZ dosya sisteminde /AKDENIZ/users dizini altında, kullanıcı tanımlamaları yapılırken sistem tarafından atanan sistem kullanıcı adıyla oluşturulacaktır. Bu dizin altında kullanıcıların herhangi bir veri tutmamaları beklenmektedir. Kullanıcılar (ki eğer birden fazla projeye üyelerse) üyesi oldukları her bir proje grubu için ev dizinleri altında bulunan, proje grubu adıyla oluşturulmuş ve ilgili projenin ana dizini altındaki kullanıcı proje dizinine yönlendirilmiş sembolik bağlantıya sahip olacaklardır.

Sunucu Sistemleri Genel Görünüm.

Her kullanıcının, ev dizininde tutacağı veriyi sadece ve sadece ilgili proje dizininde tutması gerekmektedir. Aksi bir davranış nedeniyle (örneğin A projesinin verilerinin B projesi alanında tutulması gibi) ortaya çıkacak sorun ya da karışıklıktan UHeM sistem yönetimi sorumlu tutulamayacak ve tüm sorumluluk bu işlemi gerçekleştiren kullanıcıya ait olacaktır. “Proje Ev Dizini, Kullanıcı Ev Dizini ve Kullanıcı Proje Diziniyle İlgili Örnekler” başlıklı bölüme bakarak somut örnekler üzerinden yapı hakkında daha kolay fikir edinebilirsiniz. AKDENIZ dosya sistemi sadece ve sadece Login node'lardan ve grafik arayüze sahip uygulamaların çalıştırılabileceği AGS sunucularından erişilebilir durumdadır. Kullanıcılar derleme işlemlerini AKDENIZ dosya sistemi üzerindeki ev dizinleri ya da proje ana dizini altındaki kendi seçtikleri dizinler altında gerçekleştirebilirler. Login sunucuları hesaplamaların yürütüleceği alan olan RS dosya sistemine erişebileceklerdir. Ancak bu erişim sadece derlenen uygulamaların ve girdi olarak kullanılacak verilerinin RS dosya sistemine aktarılması amacıyla kullanılabilecektir. AKDENIZ dosya sistemi hesaplama sunucularınca erişilemeyeceği için, RS altına kopyalanmamış bir veriyle hesaplama işlemleri herhangi bir sonuç ve/veya hata vermeden sonlanacaktır. RS dosya sistemi ile AKDNENIZ dosya sisteminin dizin yapısı isimleri dahil birebir aynı olacaktır. İkisi arasındaki tek fark içerik yönünden olacak, kullanıcıların aktif hesaplama yapacakları verileri dışında RS dosya sistemi altında hiçbir veri bulunmayacaktır. Kullanıcıların ev dizinlerinin bulunduğu AKDENIZ alanı hesaplama sunucularınca görülemeyecek, sadece RS dosya sistemi görülebilecektir. Kullanıcı ev dizini tanımları tek olduğu için, hesaplama sunucuları RS dosya sistemini AKDENIZ dosya sistemi olarak görecektir. Bu nedenle AKDENIZ dosya sisteminin ve RS dosya sisteminin kullanıcı ev dizini hiyerarşisi birbir aynı olacaktır.

Yazılımların Yerleri, Kullanımları ve Kod Derlemeyle İlgili Bilgiler
  • UHeM dosya sistemlerindeki yapılanma sonrasında mevcut program, derleyici ve kütüphanelerle ilgili yeni düzenlemeler yapılmamış tüm uygulamalar hem login sunucuları hem de hesaplama sunucuları üzerinden ulaşılabilecek şekilde /RS/progs dizini altında tutulmaya devam edilmiştir. /RS/progs dizini login sunucuları tarafından da görülebilir durumdadır. RS dosya sisteminin progs haricindeki diğer dizinleri login sunucuları tarafından görülemeyecektir. Bu sadece uygulamaların eski PATH'lerinin geçerli olması için bu şekilde kullanıma sunulmuştur.
  • Kullanıcıların ev dizinlerinde yer alan .bashrc, .bash_profile ve .profile gibi kullanılan kabukla ilgili dosyalar AKDENIZ dizininde oluşturulmaktadır. Ancak hesaplamaların yapıldığı sunucular AKDENIZ dosya sistemine erişemedikleri için, uygulamaların istenen ayarlarla hesaplama sunucularında çalışabilmesi için bu dosyaların RS dosya sistemine de aktarılmaları gerekmektedir. Ayrıca bu dosyalarda değişiklik yapıldığında, yapılan değişikliğin etkin olması için RS'teki dosyanın içeriği de güncellenmelidir.
  • [Kod derleyen kullanıcılar için geçerlidir] Kullanılacak olan programın kaynak koduna sahip ve kodu derlemek durumda olan kullanıcılar, kod derleme ve kod çalıştırma denemelerini login node'ların lokal disk'inde bulunan /tmp dizininde, başka dosya ya da dizin isimleriyle çakışmayacak şekilde isimlendirilmiş bir dizin hiyerarşisi içinde yapabilirler. [UYBHM paralel dosya sistemlerinin performansını düşürmemek için /tmp dizinin kullanılması önerilmekte, ancak kimi uygulama kod paketlerinin büyüklüğü göz önüne alınarak bu uygulama zorunlu tutulmamaktadır.] Kullanıcılar derlenen bu yazılımı, kod derleme ve test işlemleri sonrasında, yazılımın hesaplama düğümleri tarafından ulaşılması için öncelikli olarak AKDENIZ dosya sistemine taşımalı, sonrasındaysa kullanım sıklığı ya da şekline göre RS dizinine kopyalamalıdır. Login node'ların /tmp dizinlerinin diski doldurmaması için belirli aralıklarla bu dizin içindeki dosyalar silinecektir. Derleme ve test işlemleri sonrasında ilgili dosya ve dizinlerin kullanıcılarca silinmesi gerekmektedir. Aksi halde belirli aralıklarla yapılan temizlik sonrasında derleme işleminin yapıldığı kodlar da silinmiş olabilir.
Proje Ev Dizini, Kullanıcı Ev Dizini ve Kullanıcı Proje Diziniyle İlgili Örnekler
Varsayımlar
  1. İki adet proje ele alınsın ve bilgileri aşağıdaki şekilde olsun:
Proje Adı: Şairlerin Hayatlarındaki Önemli Olayların Ki-Kare Dağılımına Uygunluğunun Araştırılması.
Proje Kısa Adı = Unix Group Adı = Proje Ev dizini Adı: sairler
Proje Üyeleri: Neyzen Tevfik, Orhan Veli, Nazım Hikmet
Proje Üyelerinin Unix Kullanıcı Adları: ntevfik, oveli, nhikmet
Proje Adı: Neyzen Tevfik'in İcra Ettiği Ney Eserlerindeki Komalı Notaların Possion Dağılımına Uygunluğunun Araştırılması
Proje Kısa Adı = Unix Group Adı = Proje Ev dizini Adı: kompo
Proje Üyeleri: Neyzen Tevfik
Proje Üyelerinin Unix Kullanıcı Adları: ntevfik
  1. UHeM kullanıcılarından Neyzen Tevfik'in UHeM'de çalıştığı iki adet proje grubu olsun.
Kullanıcı Ev Dizinleri
Kullanıcıların ev dizinleri çalıştıkları projeden bağımsız olarak aşağıdaki şekilde oluşturulurlar:
/AKDENIZ/users/ntefvik
/AKDENIZ/users/oveli
/AKDENIZ/users/nhikmet
Proje Ev Dizinleri
Proje ev dizinleri aşağıdaki şekilde oluşturulurlar:
/AKDENIZ/projects/sairler
/AKDENIZ/projects/kompo
Proje İş Çalıştırma Dizinleri
/RS/projects/sairler
/RS/projects/kompo
Kullanıcı Proje Dizinleri
/AKDENIZ/users/ntevfik/sairler
/AKDENIZ/users/ntevfik/kompo
/AKDENIZ/users/oveli/sairler
/AKDENIZ/users/nhikmet/sairler
Kullanıcı İş Çalıştırma Dizinleri
/RS/users/ntevfik/sairler
/RS/users/ntevfik/kompo
/RS/users/oveli/sairler
/RS/users/nhikmet/sairler
Örnek 1: Kullanıcı ev dizinlerinin için geçip de “ls -l” komutunu çalıştırdığımızda aşağıdaki çıktı elde edilmektedir:
Neyzen Tevfik için;
[ntevfik@lnode1 ~]$ ls -l
sairler -> /AKDENIZ/projects/sairler/ntevfik
kompo -> /AKDENIZ/projects/kompo/ntevfik
Orhan Veli için;
[oveli@lnode1 ~]$ ls -l
sairler -> /AKDENIZ/projects/sairler/oveli
Nazım Hikmet için;
[nhikmet@lnode1 ~]$ ls -l
sairler -> /AKDENIZ/projects/sairler/nhikmet
Örnek 2: Proje iş çalıştırma dizinine geçip, “ls” komutunu verdiğimizde aşağıdaki çıktı elde edilmektedir:
12Neyzen Tevfik kullanıcısı “sairler” isimli projesinin iş çalıştırma dizinine geçerek orada “ls” komutunu verdiğinde;
[ntevfik@lnode1 sairler]$ pwd
/RS/projects/sairler
[ntevfik@lnode1 sairler]$ ls
ntevfik nhikmet oveli
Örnek 3: Kullanıcı iş çalıştırma dizinine geçilip “ls -l” komutu verildiğinde aşağıdaki çıktı elde edilir [ntevfik kullanıcısı için]:
[ntevfik@lnode1 ntevfik]$ pwd
/RS/users/ntevfik
[ntevfik@lnode1 sairler]$ ls -l
kompo -> /RS/projects/kompo/ntevfik
sairler -> /RS/projects/sairler/ntevfik

LSF Kuyruk ve Kaynak Yönetimi Altyapısının Kullanımıyla İlgili Yapılan Değişiklikler

UHeM Sunucu sistemlerinin kaynak ve zamanlama sorunu olmaksızın kullanılabilmesi için hizmete sunulmuş olan LSF kaynak ve kuyruk yönetim yazılımının kullandırılmasıyla ilgili değişiklikler yapılmıştır. Değişiklik öncesi her bir proje grubu için bir kuyruk oluşturulmuş ve kullanıcıların bu kuyruklara iş teslim etmesi sağlanmışken yeni sistemde kuyruk oluşturma mantığı değiştirilmiştir. Kullanıcılar işlerini proje grubu kuyruğuna değil, yapacakları hesaplamaların çalışma sürelerine uygun kuyruklara teslim etmek durumundadırlar.

Kuyruklar ile ilgili ayrıntılı bilgi aşağıda verilmiştir:

short
Kısa işler kuyruğu. En fazla üç (3) saat çalışması beklenen işler için ayrılmış kuyruktur. Öğrenci Araştırma Desteği programı kapsamındaki kullanıcılar hariç tüm kullanıcılar üyedir. Anadolu, Ege, Karadeniz sunucu sistemleri üzerinde bu kuyruk ile iş çalıştırılabilir. Üç saatten daha uzun süren işler otomatik olarak sonlandırılacaktır.
mid
Orta uzunlukta işlerin çalıştırılabilmesi için ayrılmıştır. Üç (3) saat ila beş (5) gün arasında iş çalıştıracak kullanıcıların kullanmasının beklendiği kuyruktur. Öğrenci Araştırma Desteği programı kapsamındaki kullanıcılar hariç tüm kullanıcılar üyedir. Anadolu, Ege ve Karadeniz sunucu sistemleri üzerinde bu kuyruk ile iş çalıştırılabilir. Beş (5) günden daha uzun süren işler otomatik olarak sonlandırılacaktır.
long
Uzun işler kuyruğu. Beş (5) gün ila 30 gün arası bir zaman aralığında çalışması beklenen işlerin teslim edilmesi gereken kuyruktur. Öğrenci Araştırma Desteği programı kapsamındaki kullanıcılar hariç tüm kullanıcılar üyedir. Anadolu ve Ege sunucu sistemleri üzerinde bu kuyruk ile iş çalıştırılabilir. 30 günden daha uzun süren işler otomatik olarak sonlandırılacaktır.
serial
Seri iş çalıştırmak için oluşturulmuş kuyruktur. Tüm kullanıcılar tarafından kullanılabilmektedir. Bu kuyruk ile bir kullanıcı aynı anda en fazla 3 iş çalıştırabilir. Toplam iş çalıştırma sınırı 12'dir. Kuyrukta iş çalıştırma sınırı yedi (7) gündür. Yedi günden uzun süren işler otomatik olarak sonlandırılır.
smp
Trakya sunucusunda iş çalıştırmak için kullanılması gereken kuyruktur. Trakya sunucusu üzerinde iş çalıştırması uygun görülen kullanıcılar bu kuyruğa üye yapılırlar. En fazla 15 güne kadar iş çalıştırılabilir. 15 günden uzun süren işler otomatik olarak sonlandırılır.
tesla
GPU destekli Tesla sunucu sistemi üzerinde iş çalıştırmak için kullanılması gereken kuyruktur. Tesla sunucu sistemi üzerinde iş çalıştırması uygun görülen kullanıcılar bu kuyruğa üye yapılırlar. En fazla üç (3) güne kadar iş çalıştırılabilir. Üç günden uzun süren işler otomatik olarak sonlandırılır.
ege2
Ege2 sunucu sistemi üzerinde iş çalıştırmak için kullanılması gereken kuyruktur. Ege2 sunucusu üzerinde iş çalıştırması uygun görülen kullanıcılar bu kuyruğa üye yapılırlar. En fazla 15 güne kadar iş çalıştırılabilir. 15 günden uzun süren işler otomatik olarak sonlandırılır.
serial_e2
Ege2 sunucu sistemi üzerinde seri olarak iş çalıştırmak için kullanılması gereken kuyruktur. Ege2 sunucusu üzerinde seri iş çalıştırması uygun görülen kullanıcılar bu kuyruğa üye yapılırlar. En fazla yedi (7) güne kadar iş çalıştırılabilir. Yedi günden uzun süren işler otomatik olarak sonlandırılır.
grad
Öğrenci Araştırma Desteği Programı kapsamında yüksek lisans öğrencileri için tanımlanmış kuyruktur. Anadolu sunucu sistemi üzerinde kullanılabilmektedir. Kuyrukta iş çalıştırma sınırı yedi (7) gündür. Yedi günden uzun süren işler otomatik olarak sonlandırılır.
grad_e2
Öğrenci Araştırma Desteği Programı kapsamında yüksek lisans öğrencileri için tanımlanmış kuyruktur. Ege2 sunucu sistemi üzerinde kullanılabilmektedir. Kuyrukta iş çalıştırma sınırı yedi (7) gündür. Yedi günden uzun süren işler otomatik olarak sonlandırılır.
ugrad
Öğrenci Araştırma Desteği Programı kapsamında lisans öğrencileri için tanımlanmış kuyruktur. Anadolu sunucu sistemi üzerinde kullanılabilmektedir. Kuyrukta iş çalıştırma sınırı yedi (7) gündür. Yedi günden uzun süren işler otomatik olarak sonlandırılır.
ugrad_e2
Öğrenci Araştırma Desteği Programı kapsamında lisans öğrencileri için tanımlanmış kuyruktur. Ege2 sunucu sistemi üzerinde kullanılabilmektedir. Kuyrukta iş çalıştırma sınırı yedi (7) gündür. Yedi günden uzun süren işler otomatik olarak sonlandırılır.
pgrad
Öğrenci Araştırma Desteği Programı kapsamında doktora öğrencileri için tanımlanmış kuyruktur. Anadolu sunucu sistemi üzerinde kullanılabilmektedir. Kuyrukta iş çalıştırma sınırı yedi (7) gündür. Yedi günden uzun süren işler otomatik olarak sonlandırılır.
pgrad_e2
Öğrenci Araştırma Desteği Programı kapsamında doktora öğrencileri için tanımlanmış kuyruktur. Ege2 sunucu sistemi üzerinde kullanılabilmektedir. Kuyrukta iş çalıştırma sınırı yedi (7) gündür. Yedi günden uzun süren işler otomatik olarak sonlandırılır.
pgrad_vlong
Öğrenci Araştırma Desteği Programı kapsamında doktora öğrencileri için tanımlanmış kuyruktur. Anadolu sunucu sistemi üzerinde toplam 16 çekirdek kullanılmasına izin verilmektedir. Kuyrukta iş çalıştırma sınırı 30 gündür. 30 günden uzun süren işler otomatik olarak sonlandırılır.

Daha önce kullanılmayan ancak proje grubu bazlı kuyruk uygulamasının kalkmasıyla kullanılması zorunlu hale getirilmiş bir LSF bsub komut opsiyonu vardır: -P <project_group_name>: “bsub” komutuna verilecek bu opsiyon zorunlu tutulmuş ve bu opsiyonu kullanmayan kullanıcıların sisteme iş teslim etmeleri yasaklanmıştır.

UHeM'de yer alan sunucu sistemleri, zaman kısıtı uygulanan kuyrukların her birine, kullanıcıların kullanım eğilimleri oranında paylaştırılmıştır. Yapılan bu paylaşım sunucu sistemlerinin işlemci çekirdeklerinin saat frekansı aynı olacak şekilde ve performans ağı bant genişliği açısından en düşük düzeyde darboğaz yaratacak şekilde gerçekleştirilmiştir. Aşağıdaki tabloda bu paylaşımla ilgili detaylı bilginin yanı sıra, sunucu sistemi ve kuyruk maliyetleri eşleşmesi de bulunabilir. Bu tablolarda verilen kuyruk başına sunucu sistemlerinden ayrılan işlemci sayısı tüm kuyruklarda eşittir. Bu sayılar, herbir sunucu sisteminin sahip olduğu toplam işlemci sayısını göstermektedir. Dolayısıyla kullanım aşamasında kuyruk başına cari işlemci sayısı hiçbir şekilde bu rakamlara eşit olmayacaktır. Buradaki rakamlar, tek bir kuyruğun, diğer kuyruklar kullanılmadığında kullanabilecekleri maksimum işlemci sayısına eşittir.

Anadolu Trakya Ege Karadeniz Ege2
short kuyruğu
Zaman Kısıtı İşler en fazla 3 saat çalışabilir İşler en fazla 3 saat çalışabilir İşler en fazla 3 saat çalışabilir
İşlemci Sayısı 860 336 512
Bsub'a ”-m” ile belirtilecek değer anadolu_dual/anadolu_quad ege karadeniz
Maliyet Katsayısı 0.60 (Harcanan 1 saniye, CPUkotanızdan 0.6 saniye düşmesi anlamına gelmektedir) 0.80 (Harcanan 1 saniye, CPU kotanızdan 0.8 saniye düşmesi anlamına gelmektedir) 1 (Harcanan 1 saniye CPU kotanızdan 1 saniye düşmesi anlamına gelmektedir)
mid kuyruğu
Zaman Kısıtı İşler en fazla 5 gün çalışabilir İşler en fazla 3 gün çalışabilir İşler en fazla 3 gün çalışabilir
İşlemci Sayısı 828 336 512
Bsub'a ”-m” ile belirtilecek değer anadolu_dual anadolu_quad ege karadeniz
Maliyet Katsayısı 0.60 0.80 1
long Kuyruğu
Zaman Kısıtı İşler en fazla 30 gün çalışabilir İşler en fazla 30 gün çalışabilir İşler en fazla 30 gün çalışabilir
İşlemci Sayısı 828 336 512
Bsub'a ”-m” ile belirtilecek değer anadolu_dual anadolu_quad ege karadeniz
Maliyet Katsayısı 0.60 0.80 1
smp kuyruğu
Zaman Kısıtı İşler en fazla 15 gün çalışabilir
İşlemci Sayısı 64
Bsub'a ”-m” ile belirtilecek değer trakya
Maliyet Katsayısı 1
serial kuyruğu
Zaman Kısıtı 7 Gün
İşlemci Sayısı 12
Bsub'a ”-m” ile belirtilecek değer seri
Maliyet Katsayısı 0.6
ege2 kuyruğu
Zaman Kısıtı 15 Gün
İşlemci Sayısı 488
Bsub'a ”-m” ile belirtilecek değer ege2
Maliyet Katsayısı 0.5
grad kuyruğu
Zaman Kısıtı 7 Gün
İşlemci Sayısı 512
Bsub'a ”-m” ile belirtilecek değer anadolu_dual anadolu_quad
Maliyet Katsayısı 0.6
grad_e2 kuyruğu
Zaman Kısıtı 7 Gün
İşlemci Sayısı 488
Bsub'a ”-m” ile belirtilecek değer ege2
Maliyet Katsayısı 0.5
ugrad kuyruğu
Zaman Kısıtı 7 Gün
İşlemci Sayısı 512
Bsub'a ”-m” ile belirtilecek değer anadolu_dual anadolu_quad
Maliyet Katsayısı 0.6
ugrad_e2 kuyruğu
Zaman Kısıtı 7 Gün
İşlemci Sayısı 488
Bsub'a ”-m” ile belirtilecek değer ege2
Maliyet Katsayısı 0.5
pgrad kuyruğu
Zaman Kısıtı 7 Gün
İşlemci Sayısı 512
Bsub'a ”-m” ile belirtilecek değer anadolu_dual anadolu_quad
Maliyet Katsayısı 0.6
pgrad_e2 kuyruğu
Zaman Kısıtı 7 Gün
İşlemci Sayısı 488
Bsub'a ”-m” ile belirtilecek değer ege2
Maliyet Katsayısı 0.5
pgrad_vlong kuyruğu
Zaman Kısıtı 7 Gün
İşlemci Sayısı 512
Bsub'a ”-m” ile belirtilecek değer anadolu_dual anadolu_quad
Maliyet Katsayısı 0.6


Yukarıdaki tablolarda belirtilen zaman kısıtı uygulaması LSF yazılımının kontrolündedir ve işler belirtilen süreler sonunda otomatik olarak LSF tarafından sonlandırılacaktır.

Yukarıdaki tablolarda verilen kuyruklara göre istenilen sunucu sistemi seçildiğinde, sistem yoğun kullanımda olduğunda, pek çok iş bekleme (PENDING) durumunda kalmaktaydı. Bunun için kullanıcının seçtiği sunucu sistemi o an için uygun değilse, teslim edilen işin PEND durumda olmaması için o an uygun olan başka bir sunucu sisteminde iş başlatılmaktadır. Yapılan bu otomatik yönlendirme LSF sunucu sisteminin varsayılan davranışıdır. Bu davranışı atlayıp, işinizin kesinlikle 16 çalışmasını istediğiniz sunucu sisteminde, uzun bir süre PENDING durumunda kalmasını göze alarak, iş teslimatı yapmak için -m ile belirtilen sunucu sisteminin sonuna “_w” son ekini eklemeniz yeterli olacaktır. Örneğin;

 bsub  -P sairler -q short -m anadolu_dual_w -o %J.out -e %J.err -a intelmpi -n
16 mpirun.lsf $PWD/app_name_to_run
LSF Kullanım Örnekleri
  • nhikmet kullanıcısı, Anadolu sunucu sisteminde 2 saat 45 dakikalık bir hesaplama yapmak istiyor. Bu durumda aşağıdaki komutu kullanarak sisteme iş verebilir [aşağıdaki komut tek bir satır halindedir].
[nhikmet@lnode1 deneme_is_dizini]$ bsub  -P sairler -q  short -m  anadolu_dual -o %J.out -e %J.err -a intelmpi -n 16 mpirun.lsf $PWD/app_name_to_run

Kullanıcının verdiği bu komut sonucunda CPU zamanı olarak harcanan süre olan 13597 saniye,kullanıcının CPU zaman kotasından 8158 saniye düşmesine neden olacaktır (CPU zamanı saat olarak ölçüldüğü için sonuçta (8158/3600=) 2.27 saatlik bir kullanım olarak kota kayıtlarına girmiş olacaktır)

  • oveli kullanıcısı çok acil olarak Karadeniz sunucu sisteminde bir iş çalıştırmak istemektedir.

Bunun için vereceği komut şu şekildedir[aşağıdaki komut tek bir satır halindedir]:

[oveli@lnode2 sample_run_dir]$ bsub -P sairler -q urgent -m karadeniz -o %J.out
-e %J.err -a mvapich -n 64 mpirun.lsf $PWD/app_name_to_run

Bu komut verilerek yapılan hesaplama sonucunda harcanan 4350323 saniyelik CPU zamanı, çalıştırılan işin urgent kuyruğunda çalıştırılmış olması nedeniyle kullanıcının CPU zamanı kotasından 21751615 saniyelik bir azalmaya neden olacaktır (Bu da 6042 saatlik bir CPU zamanı harcamasına denk düşmektedir).

  • ntevfik kullanıcısı yapacağı hesaplamada her bir process'inin 8 GB bellek kullanmasını

istemektedir. Bunun için aşağıdaki komut verilmelidir[aşağıdaki komut tek bir satır olarak yorumlanmalıdır]:

[ntevfik@lnode2 kompo_test_run]$  bsub  -P kompo -q bigmem  -m anadolu_dual -o
%J.out -e %J.err -a openmpi -n 64 mpirun.lsf $PWD/app_name_to_run

Kullanıcı process başına 8 GB'tan daha fazla bellek kullanmak istediğinde -m için anadolu_b_quad, ege_b, karadeniz_b sunucu adlarını yazmalıdır. Bunun nedeni anadolu_b_dual olarak belirtilen suncuların maliet katsayısının diğerlerinden daha düşük olması ve eğer çok fazla belleğe ihtiyaç yoksa anadolu_b_dual sunucularının daha az CPU zamanı tüketimine yardımcı olmasıdır.

Kullanıcının anadolu_b_dual belirterek yaptığı hesaplama sonucunda harcamış olduğu 30639 saniyelik CPU zamanı, kullanıcının CPU zaman kotasından 122556 saniye düşmesine neden olacaktır (Bu da 34.04 saatlik bir CPU zaman kota azalması demektir)

Yukarıdaki bsub komutlarındaki açıklananların (-P, -m ve -q) dışında kalan tüm opsiyonlar ve değerleri için UHeM web sayfasındaki dokümanlar kısmında bulunan LSF ile ilgili dokümanlara başvurabilirsiniz.

LSF ile sisteme iş verme konusunda ayrıntılı bilgi almak için UHeM Wiki Anasayfası'ndaki "Sisteme İş Verme" başlığı altındaki kaynaklardan faydalanabilirsiniz. Gaussian, Turbomole, OpenFOAM, Rosetta, MATLAB, ANSYS Fluent ve Amber gibi paket programların kullanımı için UHeM Wiki Anasayfası'nda yer alan "Paket Programların Kullanımı" başlığı altındaki kılavuzlardan faydalanabilirsiniz.

UHeM Kaynaklarının Verimli Kullanımı Hakkında

Lustre Dosya Sistemi Hakkında Temel Bilgiler

  • Paralel I/O yapmaya olanak sağlar.
  • Dosyaları striping (her bir şerit farklı bir depolama birimine denk gelecek şekilde dosyayı bölme) işlemine tabi tutar.
  • Bir dosyayı oluşturan stripe'lar (şeritler), OSS (Object Storage Server = Nesne Depolama Sunucusu)'lerin sunduğu farklı OST'lere (Object Storage Target = Lustre mantıksal depolama ünitesi) yazılırlar ve oradan okunurlar. Bu sayede geleneksel dosya sistemi yazılımlarına göre hem paralel

I/O avantajının kapsını aralamakta hem de performans artışı sağlamaktadır.

Lustre Dosya Sistemi Şeması.
Lustre Dosya Sistemi İstemcileri
Sunucu sistemlerindeki herhangi bir hesaplama düğümünü, login node'lardan ya da AGS node'larından herhangi birini ifade eder. Lustre dosya sistemini herhangi bir başka dosya sistemi gibi dizin hiyerarşisine bağlamış olan sunuculardan biridir en genel tanımla.
MDS (Meta Data Server)
Lustre dosya sisteminde depolanmış her bir dosyanın inode bilgisine erişim hizmeti sağlayan sunucudur. Her Lustre dosya sisteminde 1 adet bulunur. MDT (Meta Data Target): Lustre dosya sisteminde depolanmış dosyaların inode bilgisinin tutulduğu disk alanıdır burası. Her Lustre dosya sisteminde 1

adet bulunur.

OSS (Object Storage Server)
Lustre dosya sistemleri için asıl depolama alanı olan OST'lere erişim hizmeti sağlayan sunuculardır. OSS sayısı dosya sistemi başına birden fazladır. Dosya sisteminin performans ve disk alanı büyüklüğünde artış yeni OSS'ler eklenerek sağlanır.
OST (Object Storage Target)
Lustre dosya sisteminde stripe'lar halinde tutulan dosyaların asıl depolama alanlarını ifade eder. Bir Lustre dosya sisteminde birden fazla sayıda bulunurlar. Ayrıca OSS başına sayıları da birden fazla olabilir (OSS'nin donanımsal kapasitesine ba ğlıdır bu sayı [Bellek miktarı ve işlemci gücü...])

Temel Okuma/Yazma İşlemleri Nasıl Olur?

MDS MDT üzerindeki, dosya sisteminde bulunan her dosya için stripe sayısı, büyüklü ğü ve yerleşimi ve hangi OST'ler üzerinde tutulduğuyla ilgili bilgileri, bu bilgilere ulaşmak isteyen istemcilerin kullanımına sunmaktadır. Bir istemci Lustre dosya sistemi üzerinde tutulan bir dosyaya erişmek istediğinde,

  • MDS'ten o dosya ile ilgili bilgileri almak zorundadır.
  • Bu bilgiler MDS'ten bir kere alındıktan sonra, istemci artık MDS'e gerek duymadan doğrudan OSS'lere bağlanarak dosyanın stripe'larının bulunduğu OST'lere erişerek dosyayla

ilgili işlemleri yürütebilir.

MDS ile etkileşim halinde olmak maliyetli bir işlemdir. Dosya sistemine dair yapılacak işlerin sınırlandırılması, dosya sisteminin isteklere daha çabuk cevap vermesine yardımcı olacaktır

Temel Stripe Örnekleri

Varsayımlar:

1) Üç adet dosyamızın boyut bilgileri şu şekilde olsun.
Dosya_1 < 1 MB
3 MB < Dosya_2 < 4 MB
1 MB < Dosya_3 < 2 MB
2) Dosya sistemimiz 3 OST'den oluşsun.
Tek Stripe Örneği

Lustre dosya sistemi stripe sayısı 1'e eşit olduğunda, her bir dosyayı tek bir OST üzerinde konumlandırır. Konumlandırma işleminde hangi OST'nin seçileceği üzerinde en son işlem yapılan OST'den sonraki ilk OST olacak şekilde belirlenir. Bu sayede OST'ler arasında yük dengelemesi yapılmış olur.

Çift Stripe Örneği

Dosya sisteminde stripe sayısı 2 olarak seçildiğinde, Lustre dosya sistemi, herhangi bir dosyayı iki farklı OST üzerinde tutacak şekilde bir striping işlemi uygular. Bu durumda dosyanın büyüklüğü, ön tanımlı stripe boyutundan küçük olmadıkça tam olarak 2 farklı OST üzerine yazılmak zorundadır.

Striping İle İlgili Temel Bilgiler

Lustre dosya sisteminde ön tanımlı olan stripe sayısı ve büyüklü ğü yanında, kullanıcılar kendi programlarının I/O türü ve büyüklüğüne göre istenilen şekilde, dosya ve dizin bazında da ayarlanabilir. Bu ayarlamalara geçilmeden önce stripe boyutu ve stripe sayısı için önemli olacak noktalara de ğinilecektir:

  • Herhangi bir dosyayı gereğinden fazla stripe'a ayırmak OST'lere çok küçük parçaların yazılmasına ve

dolayısıyla da OST'lerin kaynaklarını ve OSS erişim ağını verimsiz kullanmaya neden olacaktır.

  • Bir dosya ihtiyaç olduğundan daha az parçaya bölünürse, OST'ler üzerine fazla yük binmiş olacaktır.
  • Bir dosya ya da dizin için stripe size'ı 1 MB'den daha küçük ve 4 MB'den daha büyük olacak şekilde

ayarlamak Lustre dosya sisteminin verimsiz çalışmasına neden olacaktır.

  • Bir dosyanın/dizinin stripe bilgisini almak için
lfs getstripe -q dizin_adi/dosya_adi
  • Stripe büyüklüğü ve sayısı ön tanımlı değerlerden farklı ayarlanmış bir dizinin içinde oluşturulacak her

dosya/dizin, stripe ayarlarını oluşturulduğu dizinden devralır.

  • Daha önce oluşturulmuş bir dizinin stripe bilgileri
lfs setstripe -c 2 dizin_adi

komutuyla değiştirilir. Bu komut bu dizin içinde eskiden oluşturulmuş dizin veya dosyaları etkilemez.

  • Daha önce oluşturulmuş bir dosyanın stripe bilgileri tek bir komutla değiştirilemez. Bunun için öncelikle
lfs setstripe -c 16 -s 1m yeni_dosya_adi

komutuyla 0 (sıfır) byte büyüklüğünde bir dosya oluşturulur. Sonrasında ise dosya_adi isimli eski stripe ayarlamalarına sahip diğer dosya bu dosyanın üzerine kopyalanır (cp dosya_adi yeni_dosya_adi). Son aşamda, dosya_adi isimli dosya silinir.

UHeM Dosya Sistemleri Lustre Bilgileri

RS Dosya Sistemi Bilgileri
Disk Alanı: 144 TB
OST Sayısı: 9
Ön tanımlı stripe sayısı: 1
Ön tanımlı stripe büyüklüğü: 1 MB
AKDENIZ Dosya Sistemi Bilgileri
Disk Alanı: 336 TB
OST Sayısı: 21
Ön tanımlı stripe sayısı: 1
Ön tanımlı stripe büyüklüğü: 1 MB

Lustre Dosya Sistemini Kullanmayla İlgili Kurallar ve İpuçları

Lustre alanı içinde derleme işlemi, çok zorunlu değilse yapılmamalıdır. (AKDENIZ dosya sistemi de buna dahildir)

  • “ls -l” komutu ve diğer “file stat” kavramı çerçevesinde değerlendirilecek komutlar, çok zorunlu olmadıkça Lustre alanları içinde kullanılmamalıdır.
  • Tek bir dizin içindeki dosya sayısı sınırlandırılmalıdır. Bunun en iyi yollarından biri belirli bir hiyerarşi sağlayacak alt dizin ağacı oluşturulmalı ve bir tek dizin içindeki dosya sayısı mümkün olduğunca aza indirgenmelidir.
  • Boyutu küçük olan dosyalar, örneğin büyüklüğü stripe boyutundan daha küçük olanlar tek bir stripe'a bölünmeli yani tek bir OST üzerinde tutulmalıdır.
  • İçinde pek çok küçük boyutlu dosya olan dizinler tek bir stripe kullanılarak tek bir OST üzerinde tutulmalıdırlar.
  • RS alanı içinde tutulacak dosyalar, mümkün olduğunca boyutlarına göre gruplanarak ve bu gruplara uygun olan stripe ayarlarıyla oluşturulmuş dizinlere taşınarak tutulmalıdır.
  • [Kod geliştiren kullanıcılar için] Kodun içinde dosya açma işlemi yapılacaksa, mümkünse bu işlem sadece okunabilir (read only) olarak gerçekleştirilmelidir.
  • [Kod geliştiren kullanıcılar için] Eğer bir dosyanın erişim zamanının güncellenmesi kod için önem taşımıyorsa, dosya “read only” açılırken, dosya açma flag'i “O_RDONLY | O_NOATIME” olarak verilmelidir.
  • [Kod geliştiren kullanıcılar için] Eğer 100 MB'tan daha küçük dosyalar bir grup process tarafından okunacaksa, yazılan kod, okuma işleminin ilk process tarafından yapılacağı şekilde güncellenmelidir. İlk process okuduğu verileri diğer process'lere MPI_Bcast ile iletir. Bu konuda yazılan kodun nihai amacı ve bu tür bir değişiklik sonrası bir kazanım elde edip etmediği önemlidir. Eğer kazanım elde edilmiyorsa daha ileri bir analize başvurulmalıdır.
  • [Kod geliştiren kullanıcılar için] Büyük miktarda veri paylaşacak geniş ölçekli uygulamalar yazılırken, dosya sistemi ve I/O işlemleri için bu tür işlemleri kolaylaştıracak orta katman kütüphanelerinin kullanılması düşünülmelidir. Bunlara örnek olarak ADIOS, HDF5 ve MPI-IO verilebilir.
  • [Kod geliştiren kullanıcılar için] Geliştirilen kodda okuma yazma işlemleri, verinin bulunduğu dizin ve dosyanın stripe bilgisine uyumlu olacak şekilde yapılmalı, I/O işlemleri stripe boyutuna eşit ya da daha fazla miktarda veri için istekte bulunmalıdır.

İlgili Sayfalar