Swissotel the Bosphorus, İstanbul / 15 Şubat 2012 Günümüzün Dinamik Dünyasında İdeal Depolama Ortamı: XIV Tunç Bergsan Genel Müdür Yardımcısı Anadolubank
Sınai ve tıbbi gazlar, demir çelik, LPG, doğal gaz, ağır makine imalatı ve enerji sektörlerinde faaliyet göstermektedir Yıllık 3 milyon ton sıvı çelik üretim kapasitesi, 1,5 milyar $ ihracat, 2,5 milyar $ dış ticaret hacmi 300MWH elektrik üretim kapasitesi Fitch Ratings değerlendirmesinde Türk Lirası Notu A+
TEMEL GÖSTERGELER 2011 2010 2009 Krediler 3.733 3.027 2.430 Toplam Aktif 5.781 4.488 3.829 Mevduat 3.667 2.637 2.464 Özkaynaklar 840 755 631 Net Dönem karı 85 122 120 Krediler / Aktif 65 67 63 Kredilerdeki büyüme 23 25 24 NPL 2,6 2,5 2,7 Özkaynak / Aktif 15 17 16 SYR 17,0 18,6 18,8 ROE 10,7 18,5 23,8 ROA 1,7 2,8 3,4 Rating BB BB - BB - Şube sayısı 88 86 86 Personel sayısı 1.911 1.834 1.851
Bilgi Teknolojileri Kaliteli, sürdürülebilir ve verimli proje üretimi Sürekli gelişim, sürekli iyileştirme İç kaynak kullanımı, aktif, dinamik kadro Strateji oluşumuna aktif katılım Son derece titiz satın alma prosedürlerine tabi
Gelişimin sonu var mı? Her geçen yıl (gün?) o Daha az maliyetle o Daha az personelle o Daha az eforla o Daha az kapalı kalma süresi ile o Daha yüksek performansla o Daha kullanıcı dostu uygulamalarla o ÇOK DAHA FAZLA iş sürecini otomatize etmek, olanları da günün imkanlarının sağladığı en iyi duruma getirmek zorundayız
Kurumlarınızda gerçekten «core application» diye bir konu kaldı mı? Artık internet erişiminden e-posta sistemine, anti virüs uygulamalarından dış bağlantılara, BI raporlamalarından proje yönetimi ve deployment yazılımlarına bağımlı olmayan kim var?
Günümüzde bir bankanın müşterisine uygun hizmeti verebilmesi için gerekli uygulamalar listesinde onları geçen, yüzlere dayanan sayıda uygulama var Bir banka için «core banking» uygulaması artık tek başına bir anlam ifade etmez
Sonuç olarak IT ekiplerinin kucağında giderek karmaşıklaşan yazılım, uygulama ve donanımlar birikiyor Eski bilgilerimizle bu yapıları yönetirken, hedefler doğrultusunda geliştirirken aşağıdaki yorum karşısında ne yapacağız?
Re-imagining IT - The 2012 CIO Agenda - Bard Papegaaij, Garner Research Executive Partner It s time to re-imagine IT. Radical business and technical change demands that CIOs answer new questions, rather than just find new answers to old ones.
Problem Ana bankacılık sistemleri, veri tabanı sunucuları, Kredi Kartları veri tabanları ve bunlara hizmet veren disk sistemleri haricinde yüzlerce civarında birbirinden bağımsız çalışması gereken sunucu Bu sunucuların HA yönetimi ve DR amaçlı yedeklemeleri Performans ve yönetim sorunları
Birincil Disk Sistemi Yapısı
İkincil Disk Sistemi (eski) 15K rpm, FC SCSI diskler IO single veya dual controller üzerinden geçmek zorunda Cache tüm diskler tarafından ortak kullanılmakta Tipik bir orta/orta üstü mimarili disk sistemi Gelişmiş yönetim yazılımı, fine tuning imkanı, performans problemlerine müdahale edebilme, striping ve RAID işlemleri admin tarafından yapılıyor
Çözüm Aynı yapının daha yeni, daha kuvvetli, daha yüksek kapasiteli olanından mı almak lazım? o EMC, HP 3PAR, IBM DS8000 serisi Yoksa tamamen yeni bir mantık ile mi hareket etmek lazım? o IBM XIV
IBM XIV Gen3 Teknolojisinin öne çıkan ana başlıkları Klasik FC disk iç bağlantılı yapılara göre 20 kat daha yüksek iç sistem bant genişliği, tüm kontrol birimleri dual infiniband 2x40Gbit bağlantı ile bağlı Yüksek dış bant genişliği, 20x8Gbit FC ve 11xiSCSI portu Yeni storage sistem board ve CPU tasarımı, Quadcore işlemciler Her BİR controller için 24 GB cache kapasitesi, verinin daha yüksek performansla yazılması ve okunmasını sağlamaktadır Kolay yönetim, hatalardan hızlı recover etme kabiliyeti
Kolay Yönetim
Tereddüt ettiklerimiz? 2TB 7200 rpm SAS diskler o 240GB cache, 150 civarı paralellik Veri kaybı olasılığı? o Ya RAID5-RAID6 fail olasılığı? (URE 10^14), recovery zamanı saatler/günler o RAIDX => disk recovery zamanı 20/30dk mertebesinde o SMART disk, pre-fail signs, no hotspot o Replication
Interface Interface Interface Switching Data Module Data Module Data Module
Data sürekli yedekli yapıda ve birbiriyle yedekli yapıda durur ve sistem kendini dengeler Yeni bir kontrol- kapasite birimi eklendiğinde sistem kendini eşitler Eski veya bozuk hardware çıktığında sistem kendini eşitler Sistemde bir arıza oluştugunda kendini eşitler Data Module 1 Data Module 2 Data Module 1 Data Module 2 Data Module 3 Data Module 3
Data sürekli yedekli yapıda ve birbiriyle yedekli yapıda durur ve sistem kendini dengeler Yeni bir kontrol- kapasite birimi eklendiğinde sistem kendini eşitler Eski veya bozuk hardware çıktığında sistem kendini eşitler Sistemde bir arıza oluştugunda kendini eşitler Data Module 1 Data Module 2 Data Module 3 Data Module 4 [ hardware upgrade ]
Data sürekli yedekli yapıda ve birbiriyle yedekli yapıda durur ve sistem kendini dengeler Yeni bir kontrol- kapasite birimi eklendiğinde sistem kendini eşitler Eski veya bozuk hardware çıktığında sistem kendini eşitler Sistemde bir arıza oluştugunda kendini eşitler [ hardware failure ] Data Module 1 Data Module 2 Data Module 3 Data Module 4
VMware Yapısı Ana sistem odasında muhtelif hostlardan oluşan bir VMware cluster yapısı bulunmaktadır ODM ortamında da görece daha az sayıda sistemden oluşan bir VMware cluster yapısı bulunmaktadır Sistem yüzlerce VM sunucuyu yönetmektedir Her iki site ortamında VMware SRM çalışmaktadır LUN replikasyonları storage seviyesinde XIV tarafından yapılmaktadır
VMware platformumuz vsphere 4.1 U2 seviyesindedir Her ESX host sunucuda iki adet dual port FC HBA kart bulunmaktadır Her ESX Host sunucudan XIV nin tüm interface modüllerine SAN zonlama yapılmıştır ESX Host sunucular full yedekli path yapısı ile LUN lara ulaşmaktadır
XIV VMware R/W Latency XIV öncesi ESX HOST SUNUCULARI ORTALAMA DİSK R/W LATENCY: 60-80 ms XIV sonrası ESX HOST SUNUCULARI ORTALAMA DİSK READ LATENCY:2-3 ms ESX HOST SUNUCULARDAKİ ORTALAMA DİSK WRITE LATENCY: 0 ms Sonuç olarak disk erişim süreleri olabilecek en alt seviyeye gerilemiştir
XIV VMware VAII etkisi XIV öncesi 30 GB BOYUTUNDAKİ BİR TEMPLATE TEN KOPYA ÇIKARTMA SÜRESİ : 20 dk XIV sonrası 30 GB BOYUTUNDAKİ BİR TEMPLATE TEN KOPYA ÇIKARTMA SÜRESİ : 2 dk Sonuç olarak XIV VAII desteği ile ortak disk operasyonlarında (Migration, Template ten Clone yaratma ve diğer benzer SCSI rezervasyon işlemleri) 10 kat performans artışı sağlanmıştır
ACL Data Mart işlemleri XIV öncesi Belli raporlarda 3-4 saatlere varan hesaplama, veri oluşturma süresi XIV sonrası Aynı raporların hesaplama ve veri oluşturma süresi 1 saat Sonuç olarak kompleks veri sorgulama ve yazma işlemlerinde de 3-4 kata varan performans artışı sağlanmıştır
SQL BI raporlama XIV öncesi 3 günlük toplam 1676 raporun çekilme süresi 40 dk 27sn XIV sonrası 3 günlük toplam 2105 raporun çekilme süresi 27 dk 23sn SQL ile BI işlemlerinde 2 kat performans artışı sağlanmıştır
UNIX Performansı Sunucu XIV öncesi açılış süresi (sn) XIV sonrası açılış süresi (sn) İyileşme XIV öncesi kapanış süresi (sn) XIV sonrası kapanış süresi (sn) İyileşme A 25 23 %2 50 35 %30 B 80 42 %52 12 10 %17 Sunucu XIV öncesi write speed (MB/sec) XIV sonrası write speed (MB/sec) İyileşme XIV öncesi read speed (MB/sec) XIV sonrası read speed (MB/sec) İyileşme C 25.2 196 %700 23.3 118 %500
Yedekleme Performansı XIV öncesi A sistemi o148,415,280,987 byte veri boyutu o418.00 MB/min o508 dakika yedekleme süresi B sistemi o237,368,390,618 byte veri boyutu o575.00 MB/min o611 dakika yedekleme süresi XIV sonrası A sistemi o150,265,083,924 byte veri boyutu o2,583.00 MB/min o71 dakika yedekleme süresi B sistemi o238,468,675,667 byte veri boyutu o2,724.00 MB/min o98 dakika yedekleme süresi A sisteminde %715 B sisteminde %623 performans artışı sağlanmıştır (diğer yedekleme işlemlerinde %170-%260 aralığında iyileşme olmuştur).