Nedir Bu Mainframe Dediğimiz Şey?

Bu yazı, Garanti BBVA Teknoloji’de Z Cloud Computing Technologies Team Manager olarak çalışan Ahmet Alper Tecimer tarafından yazılmış, ayrıca kendi LinkedIn sayfasında da paylaşılmıştır.

Bu hafta Türk bankacılık sektörünün yaşadığı talihsiz olaylardan sonra özellikle sosyal medyada hem üzerinde çalıştığımız platform olan Mainframe (Ana Bilgisayar) hem de değerli meslektaşlarımız hakkında çok sayıda haksız ve dayanaksız yorum yapıldı, birçok eksik veya yanlış bilgi paylaşıldı. Konunun Türkiye’deki az sayıdaki uzmanlarından birisi olarak Mainframe’i bir nebze tanıtmak ve hakkındaki bilgi kirliliğini gidermek için bir yazı yazmak istedim. Öncelikle belirteyim ilgili kesinti hakkında yorum yapmayacağım. Bunun bir sebebi elimde gerçekliği şüpheli söylentiler dışında yeterli bilgi olmaması diğer sebebi ise sistemlerin kurtarılması için gece gündüz çalışan meslektaşlarıma saygısızlık etmek istememem. Sonuçta iki motoru da durmuş bir uçağın nereye ve nasıl indirileceği konusunu ayakları yere basıyorken yorumlamak çok kolay. (Bkz. Sully: Miracle on the Hudson filmi)

Konumuza dönecek olursak; Mainframe (ana bilgisayar) sistemleri, en özet haliyle söylersek, yüksek performans ve kapasiteye sahip bilgisayar sistemleridir. Büyük kurumların veri merkezlerinde, merkezi yapıda konumlandırılıp çok yüksek sayıda işlemin tutarlı ve hızlı bir şekilde tamamlanabilmesi için kullanılırlar. Yıllar içerisinde farklı marka ve modelleri piyasaya çıkmış olsa da günümüzde kullanılan modelleri IBM Z sunucuları ya da kısaca Z olarak isimlendirilmektedir. IBM yaklaşık olarak iki senelik döngülerle bir büyük/bir küçük Z modelini üreterek piyasaya sürer. En güncel modelleri IBM z15’lerdir (Bkz. En son 5 nesil Z sunucu). IBM Z Sunucular üzerinde z/OS, Linux, z/VM gibi işletim sistemleri ve hatta Openshift Platformu bile çalışabiliyor olsa da bunlardan en yaygın olanı ve benim de kişisel favorim z/OS’dir.

Yazının bundan sonrasında doğru sanılan bazı yanlışlar üzerinden devam etmek istiyorum:

   “Mainframe’ler 20 yıl öncesinden kalma çok eski sistemler” 

İlk mainframe 1964 yılında üretilmiş olsa da yaklaşık olarak her iki senede bir hem donanım hem işletim sisteminin yeni versiyonu çıkmakta, düzenli olarak yayınlanan güncelleme (MCL/RSU) paketleri ile hatalardan arındırılıp birçok modern özellik kazandırılmakta. Ancak burada dikkat edilmesi gereken bir nokta var yeni modellere geçmek, yazılım güncellemelerini hayata geçirmek Mainframe’i kullanan kurumun sorumluluğunda. Kendi şahit olduğum uç bir örnekle anlatacak olursam bugün artık Mainframe üzerinde çalışmayan bir kurumun 20 yıl önceki en güncel Mainframe sistemlerini bir defa kurdurduktan sonra hiçbir donanım/yazılım güncellemesi yapmadan sadece kendi uygulamalarında geliştirmeler yaparak bu sistemi 20 yıl boyunca işlettiklerini gördüm. Ta ki artık disk dayanamayarak arıza verene kadar. Böyle bir sistem için güncel ya da modern demek tabi ki mümkün değil. Ancak işin güzel tarafı Türkiye’de mevcutta Z kullanan banka ve kurumlarımız için böyle kötü bir durum söz konusu değil. Bu örnekteki gibi yıllarca güncellenmeyen Mainframe ortamlarının eski/legacy olduğunu söylemek mümkün. Donanım olarak güncellendiği halde üzerinde geliştirilen uygulamaların yenilenmediği ortamlar için de bunu söylemek yine mümkün. Ancak yeni nesil bir Z sunucu kullanıp, güncel teknolojileri hayata geçiren, geliştirdiği yazılımlarını yenileyen bir Z ortamı için bunu söylemek, ilk modelleri 1920’lerde üretildiği için günümüzdeki Toyota araçlar için “Çok eski arabalar ya hiç modern değil” demek gibi bir şey.

Bonus bilgi 1: Bir adet z15 Mainframe’i 5.2 GHz’lik 190 CPU ve 40 TB’a kadar bellek (disk değil 😊) ile konfigüre etmek mümkün. 

Bonus bilgi 2: Mainframe kullanan ortamlarda günlük milyarlar seviyesinde ticari işlemi (business transaction) ortalama 25-30 milisaniye response time ile çalıştırmak, buna paralel olarak on binlerce batch işi zamanlı bir şekilde çalıştırıp bitirmek mümkün.

“Mainframe’ler için yeni ürün, kod geliştirilmiyor”❌ , “IBM’e mecbursun” ❌ , “Sadece siyah ekran, modern teknolojileri desteklemiyor” 

IBM dışında Broadcom, BMC, Rocket Software gibi çok sayıda şirket Z için yazılım geliştirmekte. z/OS işletim sistemi tamamen kendine özgü bir işletim sistemi olsa da üzerinde tam fonksiyonel bir UNIX ortamı çalışmakta (POSIX uyumluluğu). z/OS için dönüştürülmüş bir çok Açık Kaynak yazılım bulunmakta (Python, PHP, Git, OpenSSL vs. Bkz. https://www.rocketsoftware.com/zos-open-source/tools )

z/OS’e erişim yöntemlerinden birisi TN3270 (siyahımsı ekran) olsa da, bugün bir yazılımcının hiç siyah ekran görmeden Eclipse tabanlı bir IDE, Git, Jenkins, Bitbucket gibi DevOps tool’larından faydalanarak kod geliştirip, üretime alması mümkün. (Bu yapının hayata geçirildiği bir bankacılık ortamı hakkında detaylı bilgi almak isterseniz Garanti BBVA’dan Umut Arslan’ın Z DevOps Transformation sunumunu izleyebilirsiniz: https://player.vimeo.com/video/508558813 ).

Bonus Bilgi: z/OS üzerinde Linux Container çalıştırmanın mümkün olduğunu söylemiş miydim 😊

“Bankalarda tek bir Mainframe (Ana Bilgisayar) varmış, her şey onun üzerindeymiş.”  “Yedek yokmuş, High Availability/Disaster Recovery çözümleri yokmuş.” 

Çok değişik konfigürasyonlar olsa da tipik bir Mainframe ortamında genelde paralel çalışan en az 2 Mainframe sistemi bulunur. Bu Mainframe’lerden her biri gerektiğine diğer makinenin ortalama yükünü kaldırabilecek kapasiteye çıkabilecek şekilde yedek kaynaklar bulundurur. Her Mainframe üzerinde de çok sayıda LPAR (bir nevi sanal makine) çalışabilir. Her LPAR üzerinde de DB2 gibi veritabanı sistemleri ve CICS/WAS gibi transaction/uygulama sunucuları çalışır. Parallel Sysplex denilen yapı sayesinde aynı veya farklı Mainframe üzerindeki LPAR’ları aynı işi yapıp/aynı veriyi işleyecek gruplar halinde(sysplex/cluster) çalıştırmak mümkündür. Bu LPAR’lar arasında yük dağılımı yapmak, kesintisiz olarak birini devre dışına alıp bakım işlemek mümkündür.

Tüm bunların dışında z/OS üzerinde çok sayıda recovery mekanizması bulunmakta. Tüm Mainframe bankaları ana veri merkezlerinde verileri minimum iki ayrı disk kutusuna eş zamanlı olarak yazarken, uzak bir şehirde bulunan olağanüstü durum merkezlerine ise asenkron olarak minimum bir kopya daha yazmaktalar. Bu arada senkron kopyalar arasında da kesintisiz geçiş (HyperSwap) yapmak mümkün. Bilmiyorum bugüne kadar kaç defa müşterilerimiz veya sistemde çalışan kullanıcılar hiçbir şey hissetmeden bu diskler arasında kesintisiz geçişler yaptık. Bunların dışında disk kutularının kendi içinde RAID yedekliliğinden; günlük, haftalık veya aylık alınan 10 yıla kadar sürelerle saklanan birkaç farklı çeşit yedekleme(backup) tiplerinden hiç bahsetmiyorum bile.

“DB2 çok hantal bir veri tabanı. Hala nasıl kullanılıyor anlamıyorum” 

Öncelikle DB2 for z/OS ile DB2 LUW’nin farklı veri tabanı sistemleri olduğunu belirtelim. Birçok insan aynı olduğunu düşünüyor. Mainframe’lerde kullanılan DB2 for z/OS tam bir performans canavarı diyebiliriz. (Buradan DB2 LUW’nin performansı kötü anlamı çıkmasın, sadece farklı database sistemleri olduğunu belirtiyorum.) Parallel Sysplex denilen teknolojinin de kullanımı ile 32 farklı DB2 sistemini eş zamanlı ve yüksek performanslı olarak aynı veriyi okuyup yazabilmesi mümkün. Bu DB2 sistemlerini farklı LPAR ve Mainframe’ler üzerinde konumlandırmak, böylece bir DB2 sisteminde veya Mainframe’de sorun veya bakım çalışması olduğunda işlemlere kesintisiz olarak diğer DB2 sistemlerinden devam etmek de mümkün.

Bonus Bilgi: Mainframe ortamlarında bir günde yüzlerce milyar SQL sıkıntısız ve yüksek performanslı olarak çalıştırılabilir.

Mainframe’in hiçbir problem olmadığında bile kapatılıp/açıldığında çalışmaya başlaması saatlerce sürüyormuş.  Mainframe diskleri SSD olmadığı için çok yavaşmış. 

Normal şartlarda Mainframe’ler donanım olarak açıldıktan sonra emekli edilene kadar hiç kapatılmamak üzerine tasarlanır, donanımlar yedeklidir, firmware güncellemeleri ve arıza durumunda parça değişiklikleri (CPU, Memory, I/O kartları, Power Supply dahil) makine ayaktayken kesintisiz yapılabilir. Sadece çok istisnai durumlarda donanım kapatıldığında ya da ilk kurulumda donanımın ayağa kalkması sırasında donanım olarak mainframe’in açılması söz konusu olur. Türkiye’de en çok sayıda Mainframe kuruluşunda çalışmış uzmanlardan birisi olarak benim tecrübelerimde bu süre 15-30 dakika arasındadır. Bu kadar uzun sürmesinin sebebi ise makinenin “Kapandıysam, kesin olağanüstü bir durum vardır. Uçtan uca tüm parçalarımı kontrollere tabi tutmalıyım.” pimpirikliliği 😊

Bunun haricinde işletim sistemi seviyesinde problem veya bakım çalışmalarında kapatılan Mainframe’in kendisi (donanım) değil, üzerinde bulunan LPAR’lardır. Bunların açılış süresi de manuel yapılan kontrolleri saymazsak dakikalar mertebesindedir ki bu sürede de genelde yedek makine veya LPAR hizmet vermeye kesintisiz devam etmektedir. Tabi ki ciddi bir problem olması, veri kurtarma gerektiren bir durum yaşanması, ciddi değişiklikler sonrası logların detaylı incelenmesi gerektiği durumlar süreyi uzatabilir ancak normal bir açılış için bunu söyleyemem 😊

SSD konusuna gelirsek, bugün birçok Mainframe kullanıcısı disk olarak IBM veya başka firmaların tamamen flash olan disklerini kullanıyor. Yani klasik (SAS) disk kullanımı yok denecek kadar az. Daha da önemlisi bu disklerde terabaytlar seviyesinde cache bulunuyor. Disklere yazma işlemleri zaten doğrudan cache’lere yapılırken read’ler de tipik bir z/OS ortamında %95’den daha fazla oranında cache’lerden yapılıyor.

Bonus Bilgi:

Donanım’ın ilk açılma süresinden yukarıda bahsetmiştim. LPAR/İşletim Sistemi seviyesinde şahit olduğum bazı kapanıp/açılma sürelerini de paylaşmak isterim. İlk ikisi veri merkezi taşınmaları. Burada ilk uygulamanın kapatılması disk operasyonları, kopyalamaların geri dönüş için ters yönlü başlatılması ve tüm uygulamaların ayağa kalkması dahil süreler:

  • Banka olmayan bir Mainframe kullanıcısının veri merkezi taşınmasında: 53 dakika
  • Bir banka’nın veri merkezi taşınmasında: 1 saat 50 dk. 
  • 8 LPAR’lı bir sysplex’i tek seferde kaybettikten sonra, problemin anlaşılma süresi de dahil tüm LPAR ve uygulamaların ayağa kalkma süresi: 23 dakika.

“Mainframe her şey için en iyi çözümdür. Her eve lazım.” 

Hiçbir IT çözümünde böyle bir şey söylemek mümkün değil. Mainframe kullanıcılarının hepsi başka amaçlar için Mainframe dışı sistemler de kullanmaktadır. Yapılacak işin gereksinimlerine göre fayda/maliyet analizi yapılıp uygun sistem belirlenir. Mainframe’in en iyi çözüm olduğu durumlar olduğu gibi, Mainframe kullanmanın gereksiz hatta yanlış olduğu durumlar da vardır. Bu konuda çok kullanılan bir benzetme var spor araba, pikap ve tır örneği. Kişisel bilgisayarlarımızı spor araba, diğer sunucuları pikap-kamyon, Mainframe’i de tırlara benzetirsek; spor araba veya pikapla devasa rüzgâr tribünü pervanelerini taşımak mümkün ve mantıklı olmadığı gibi, tırla da pikniğe gitmenin mantıklı olmadığı söyleyebiliriz.

“Mainframe uzmanlarının hepsi 60 yaşının üzerindeymiş ve Türkiye’de bu konuda bilgili kimse yokmuş” 

Türkiye’de oldukça küçük bir topluluk olsak da uzmanların yaş ortalaması dünya geneli ile kıyasladığımızda oldukça düşük. 40 yaşının altında da çok sayıda Mainframe/Z uzmanı bulunuyor. Bugüne kadar çalıştığım iki kurum da yeni mezun mühendislerin bu konuda uzman olarak yetiştirilmesi için düzenli olarak eğitim/staj programları organize ediyor. Ayrıca Türkiye’deki Mainframe topluluğumuzda dünya çapında ünü ve ödülleri olan, bu konuda tezler hazırlayıp akademik makaleler yayınlayan, patentleri bulunan, uluslararası dizayn komitelerinde bulunup Mainframe’in gelişimine katkıda bulunan ve birçok uluslararası konferansta defalarca sunum yapmış çok değerli ve bilgili arkadaşlarımız var.

Burada bir açıdan gurur verici ama ülkemiz için bir açıdan da üzücü bulduğum şöyle bir durum da var: Türkiye’deki yetişen ancak yurtdışına göç eden çok sayıda Z uzmanımız da var. Yeni Zelanda, Kanada, İngiltere, Almanya, Polonya, Çekya ve Suudi Arabistan gibi birçok ülkede Türkiye’den giden ve hala aktif olarak çalışan çok sayıda uzmanlarımız var.

“Ben Mainframe üzerinde çalıştım, mainframeler … sistemler”, “z/OS ve z/VM Kernel’ı Linux tabanlıymış”, “Mainframe’ler, bizim AS/400 Sistemleri işte” 

Bazen hayatlarının bir noktasında yıllar önce bile olsa yolu bir şekilde Mainframe ile kesişmiş veya mainframe üzerinde yazılmış bir uygulamayı kullanmış arkadaşlarımız, bu deneyimden yola çıkarak Mainframe’in tamamı hakkında yanlış ifadeleri çok kesin bir dille ifade edebiliyorlar. Tıpkı doktorlarda olduğu gibi bizde de ayrı ayrı uzmanlık alanları var. Mainframe ile çalışılan rollerden sadece birisi olan Sistem Programcılığında bile İşletim Sistemi, Veritabanı, Middleware, Network, Güvenlik gibi çok sayıda alt uzmanlık bulunuyor ve Mainframe insanları olarak bizim bile hepsini bilmemiz, hepsinde uzmanlaşmamız pek mümkün değilken bu kadar kısa sürede Mainframe hakkında doğru fikir sahibi olmak maalesef ki pek mümkün olmuyor. Yine de söyleyelim:

  • Hayır, Mainframe üzerinde Linux çalıştırmak mümkün olsa bile ne z/OS ne de z/VM işletim sistemleri Linux tabanlıdır. Kökleri Linux’den çok daha öncesine dayanan farklı işletim sistemleridir.
  • Hayır, AS/400 sistemleri ile Mainframe’ler tamamen farklı sistemlerdir.

“Peki tüm bunlara rağmen kesinti nasıl olabiliyor?”

Mainframe ortamlarında tüm parçalar çok sayıda yedekli bulunduğu halde, hemen her konuda kurtarma (recovery) mekanizmaları olduğu halde, veriler için çeşit çeşit yedek(backup) alındığı halde diğer birçok IT sisteminden daha az sayıda olsa da yine de problemler olabiliyor. Kimi zaman bir bug’dan ötürü, kimi zaman insan hatasından, kimi zaman öngörülemeyen istisnai durumlardan vs. vs. Bu problemlerin birçoğu bu kurtarma mekanizmaları sayesinde müşterilere hiçbir yansıması olmadan çözülebilse de bazen bir problem eş zamanlı tüm yedekli sistemleri etkileyebilmekte, yedekler kullanılamaz hale gelebilmekte. Bir çoğunuz “Uçak Kazası Raporu” belgesellerini izlemişsinizdir. Tıpkı bir uçak kazası gibi, Mainframe’de oluşan kesintiler de hem Mainframe kullanan firmalar hem de IBM gibi üretici/geliştirici firmalar tarafından hassasiyetle incelenip sebepleri belirleniyor. Aynı sorunun bir daha oluşmaması için gerekli aksiyon planları alınarak, ihtiyaç halinde donanım veya yazılım seviyesinde önleyici geliştirmeler de yapılıp tüm dünyadaki Mainframe kullanıcılarına ulaştırılıyor. Nasıl ki uçaklar uçmaya devam ettiği sürece eninde sonunda yeni uçak kazaları yaşanacaksa IT sistemleri de kullanılmaya devam ettiği sürece kesintiler oluşacaktır. Önemli olanın bu kesintilerden teknik ve teknik olmayan konularda gerekli dersleri çıkarıp, aynı problemleri tekrar tekrar yaşamamak olduğunu düşünüyorum. Mainframe’leri merak edip, bu yazıyı sonuna kadar okuduğunuz için hepinize teşekkür ederim 😊

Etiketler