Bu makaleyi yazmaya, ülkemiz gündemine yakın zamanda giren ve kamu kurumlarında OSS, daha da geniş bir yorumla FOSS kullanımını çerçevelemeyi hedefleyen kamu iradesinin ortaya çıkışı ile karar verdim. FOSS araç gereçlerle bir BT sisteminin hangi bölümlerinde neleri ne kadar karşılarız bunu size sunmaya çalışacağım. Başlarken birkaç hususta mutabık kalmamız lazım. Bu nedenle konuya kategorik olarak nasıl yaklaştığımı izah etmek isterim. Bilişim araç gereçlerini ezelden beri iki kısımda incelerim;
- Masaüstü / Son Kullanıcı araç gereçleri
- Sunucu / Backend sunucu araç gerçleri
Bunun için de kendimce haklı bir gerekçem var; Son kullanıcı dediğimizde insandan, doğal olarak bir kültürden bahsediyor oluruz. Bu alandaki yargılar ve buna bağlı kararlar hep subjektif olarak kalır ve irrasyonel bile olsa kabul görebilir doğal olarak. Stratejik her hamle de mevcut kültürle kıran kırana savaşmayı gerektirir ki çoğu zaman boşuna bir uğraşıdır bu (Druker ağabeyin kulakları çınlasın)
İkinci başlık ise daha rasyonel bir zemine işaret eder. Bu alanda da insan bir faktördür ama ana faktör değildir. Bir de bu alanda karşımıza çıkan profesyoneller nispeten daha rasyonel yaklaşımlar sergileyeceklerdir (yani öyle umuyorum).
Bu kadar izahat yeterli sanırım. Buradaki bilgiler Fiziksel zeminden IaaS a kadar, yani VM teslimatına kadarki kısmı içeriyor. Konteynerizasyon tarafına ilerlediğimizde, ya da PaaS a doğru giderken bambaşka hikayeelerimiz var elbet. Aşağıda vereceğim tablo, tabandan tavana kadar, bir servisin son kullanıcıya erişebilmesi için gerekli sistemlerde uzun zamandır kullandığım FOSS araçlardan oluşuyor. Yani internette arayıp, yorumlardan esinlenerek değil, bizatihi canlı sistemde kullandığım araçları bulacaksınız burada. Detay merak ediyorsanız benimle temasa geçmekten çekinmemenizi özellikle istirham ederim.
| Bileşen | FOSS Araç(lar) | Kapalı Kod Araçlar | Yorumum |
|---|---|---|---|
| Altyapı Yönetimi | OpenDCIM, LibreNMS, Zabbix, Kuma vb | Üreticilerin kendi geliştirdikleri araçlar | Hibrit yapılarda çoklu araç kullanımını beraberinde getirir. Örneğin UPS leri ups üreticisinin, PDU ları pdu üreticisinin, CRAC leri de crac üreticisinin sistemi ile izlemek zorunda kalırsınız. Ya da tüm araçlar hep aynı üreticinin olması gerekir |
| Sunucu İşletim Sistemi | Linux (RedHat*, Pardus, Ubuntu, Debian) | VMware, Windows | Bir üst katmanda kullanacağımız sanallaştırma katmanındaki clustering gereksinimleri nedeni ile freebsd tabanlı sistemleri bu aşamada kullanmıyorum. Redhat'ı FOSS olmamakla birlikte OSS kategorisinde değerlendiriyorum |
| İşletim Sistemi/Servis Provisyonu | MaaS | VMware AutoDeploy | Fiziksel host sayısı arttıkça olmazsa araçlardır |
| Tip 1 Sanallaştırma Katmanı | KVM | Vmware, Hyper-V | Bu aşamada ihtiyacımız olan şey, paylaşımlı ya da dağıtık bir depolama sistemini kullanabilen araçlar. GFS2, CFS, CEPH, GlusterFS ilk anda aklıma gelenler. Nedense CEPH hep özel ve öncelikli benim için. |
| Orkestrator | Proxmox | Üretici yazılımı | Proxmox'u tek verme nedenim, bir üst katmanda yer alacak olan iş sürekliliği için geliştirmiş oldukları Proxmox Backup server. Bu olmasa ve iş sürekliliği için başka yöntemler olsaydı onları da eklerdim. Eminim bir sürü yazılabilir buraya |
| Paylaşımlı Dosya Sistemi | GFS2, GlusterFS, CEPH, NFS | VMFS, CFS | Açık kaynak tarafta NFS'i verme nedenim, snapshot alırken VMWare'in NFS3 volumelerde VM'i freeze etmesi nedeni ile. Yoksa o tarafta da kullanıyoruz |
| İş Sürekliliği | Proxmox Backup Server, ZFS Replication, HCI dosya sistemleri | Veeam, Vinchin | İmaj bazlı yedekleme, yedek doğrulama |
Elbette operasyon gereklilikleri nedeni ile her araç her senaryoda çalışmayacaktır. Bununla birlikte iddia ediyorum ki, kendi iç servislerini host eden bir veri merkezi / sistem odasının IaaS platformu yeterli güvenlik seviyesinde kolaylıkla FOSS araçlarla tasarlanabilir ve hayata geçirilebilir. Şimdi soruyorum, böylesi bir dönüşümün bize, ülkemize ve dünyaya faydası nedir ? Tartışmaya değer değil mi ?
