Gruppo API, Uygulama Seçimlerinde Daha Fazla Özgürlük İçin

Gruppo API, Uygulama Seçimlerinde Daha Fazla Özgürlük İçin

Transworld Data Başarı Öyküsü
Gruppo API, Uygulama Seçimlerinde Daha Fazla Özgürlük Đçin Dağıtılmış
Platformları System z10 Üzerinde Konsolide Ediyor
25 ayrı şirketten oluşan Gruppo API (www. apioil. com) , Đtalya'nın önde gelen
yerel petrol şirketlerinden biridir. Kuruluş, Đtalya çapında yaklaşık 4.100 benzin
istasyona sahiptir ve yerel pazarın yaklaşık yüzde 11'ini elinde tutmaktadır.
Gruppo API, petrol çevriminin üretim sonrası aşamalarının tümleşik
yönetiminden, özellikle ham petrolün tedarik edilmesinden ve ticaretinden rafinaj,
lojistik ve pazarlama aşamalarına ve bunların dağıtım ile satış gibi türevlerine
kadar tüm operasyonlardan sorumludur. Kuruluşun toplam petrol rafinaj
kapasitesi dört milyon tonun üzerindedir, bunun 3,9 milyon tonu Adriyatik
Denizindeki Falconara Marittima rafinerisinde ve 230.000 tonu Đtalya'nın
Ravenna şehrindeki Alma rafinerisinde işlenmektedir. API aynı zamanda, yılda
iki milyar kilovat saat elektrik üretmektedir.
Gruppo API, 1969'dan bu yana temel işlemleri için IBM System z kullanmaktadır,
ancak veri merkezinde kısa süre öncesine kadar toplam 60 adet Intel tabanlı
Linux sunucusu ve IBM RS/6000 AIX Unix makineleri de bulunuyordu. Şirket
büyümeye devam ederken, API BT yönetimi de sunucuların konsolide edilmesi
ve Linux gibi hem esnek platform oluşturma seçenekleri sağlayacak, hem de
yazılım lisanslama ve devreye alma maliyetlerini düşürecek açık uygulama
platformlarının kullanımının artırılması stratejisi aracılığıyla veri merkezini iş
büyümesine uyum sağlayacak şekilde konumlandırmak istiyordu. "Çok daha
fazla sayıdaki satıcı firmanın ürün seçeneklerinden yararlanmamıza olanak
sağladığı için bir açık ortam oluşturmak istiyorduk," şeklinde açıklıyor API
Teknoloji Müdürü Gaetano Scebba. "Linux platformumuzu genişletmenin bunu
yapmanın en iyi yolu olduğunu düşündük."
Artan BT Mimarisi Gereksinimlerinin Tanımlanması
API BT için ilk sorun, Linux'un (ve aynı zamanda UNIX'in) dağıtık sunucu
düzeyinde konumlandırılması ya da veri merkezi ortamının bir System z fiziksel
sunucusunda sanallaştırılması arasında seçim yapılmasıydı. "SAP uygulama
sunucusunu UNIX üzerinde, SAP DB2 veritabanını System z üzerinde
çalıştırıyorduk," şeklinde açıklıyor Scebba. "Elektronik posta sistemimiz, bir veri
yönetimi sistemi ve Đnternet güvenliği ile kimlik doğrulama sistemlerimiz de
UNIX üzerindeydi." Operasyonun Intel tarafında ise sunucular Microsoft
uygulamalarını desteklemekteydi ve sanal VMware ortamında çalışmaktaydı.
"Dağıtılmış UNIX ve Linux sistemlerimiz kısa sürede 60 sunucuya ulaşmıştı ve
bu ortamın yönetilmesinde giderek daha fazla zorlanıyorduk," şeklinde açıklıyor
Scebba. Tüm bu varlıkların yaşam çevrimlerinin ayrı ayrı envantere eklenmesi ve
yönetilmesi gerekiyordu. Ayrıca, API'nın kurumsal ağı genişlerken sunucuların
izlenmesi ve yönetilmesi de sorun teşkil ediyordu. Sunucular eklendiğinde,
sunucuların kullandığı depolama kaynaklarının sürekli olarak yeniden
yapılandırılması ve kablolarının yeniden bağlanması gerekiyordu. "Buna ek
olarak, güvenilirlik konusunda da biraz endişeliydik," şeklinde açıklıyor Scebba.
"Ana bilgisayar tabanlı olmayan sistemler için, yüksek düzeyde sağlanabilirliğin
sağlanması amacıyla her zaman yedek yapılandırmalar uyguluyorduk. Dağıtık
ortamda ister x86 olsun, ister HP, RS/6000 veya Sun platformu olsun her türlü
makinenin arızalandığını gördüm, ancak 29 yıllık BT deneyimine sahip olmama
rağmen System z ile çalışırken hiçbir zaman kurtarılması mümkün olmayan çok
büyük hasarın oluştuğu bir arızaya şahit olmadım."
Bu bilgiyi planlama aşamasında göz önünde bulunduran Scebba ve ekibi, aynı
zamanda genişleyen iş operasyonlarının desteklenmesi için gerekli olabilecek
çeşitli gelişmekte olan BT altyapısı gereksinimlerini de göz önünde
bulundurmuştur. Bunların tümü, mevcut dağıtılmış bilgi işlem ortamının
yetersiz olabileceğini düşündükleri alanlardır. Ek altyapı gereksinimleri
arasında:
BT altyapısı yönetimini basitleştirme gereksinimi. Bir dağıtılmış ağa giderek
daha fazla sunucu eklenmesi, ağın genel yönetimini daha karmaşık hale
getirmekteydi.
Olağanüstü durumdan kurtarmaya yönelik basit, fazlasıyla güvenilir ve uygun
maliyetli bir yaklaşım. Dağıtılmış ağdaki tek hata noktalarının önlenmesi
zorlaşıyordu ve bu durum da hata durumunda geçiş yapılacak yedek sunucular
oluşturulmasını gerektiriyordu.
Veri merkezindeki işletim maliyetlerini düşürme gereksinimi. Dağıtık sunucu
ortamı, yazılım lisanslama ve enerji maliyetlerinin artmasına neden oluyordu.
"Bu projeye başlarken birincil hedefimiz, satın alabileceğimiz uygulamalarda bize
esneklik sağlayacak açık bir bilgi işlem ortamı oluşturmak olsa da, veri
merkezinin maliyet, güvenilirlik, arıza durumunda yedek sisteme geçiş ve altyapı
yönetimi alanlarındaki performansının da önemli olduğunu gördük," şeklinde
açıklıyor Scebba. "Bizim için soru, bir System z sunucusunun tüm bu alanlarda
gereksinimleri karşılamasının ve bizim için çok sayıda dağıtık platformu tek
System z ortamında beklediğimiz sistem güvenliğine sahip olacak şekilde
konsolide etmenin mümkün olup olmadığıydı."
Proje Tanımı
Sorunun yanıtını bulmaya kararlı olan API, konsolidasyon projesini dağıtılmış
ağın UNIX tarafında başlatmıştır. Đlk adım, şirketin System z/9 sunucusunun
2009 yılı başında System z10'a yükseltilmesi olmuştur. "System z10 sunucusunu
yedi adet IFL (Integrated Facility for Linux) işlemcisi, iki adet CP (merkezi işlem)
işlemcisi ve bir adet zIIP (System z Integrated Information Processor) işlemcisi
ile donattık," şeklinde açıklıyor Scebba. "Mevcut UNIX sunucularımızın tamamını
System z yapısı kapsamında konsolide etmek için düşündüğümüz ortam buydu."
API BT birimi, projenin ilk iki ayı içinde sadece System z/9 sunucusunu System
z10'la değiştirmekte kalmamış, aynı zamanda System z için planlanan
sanallaştırılmış bilgi işlem ortamına hazırlık amacıyla BT altyapısında da bir dizi
değişiklik gerçekleştirmiştir. "Bu aşamadaki birincil hedefimiz, zLinux kullanarak
tüm UNIX sunucularımızı konsolide edecek bir platform sağlamaktı, bu şekilde
sistematik olarak UNIX tabanlı uygulamaların bir System z ortamına
geçirilmesinin başarılı olup olmayacağını belirleyebilecektik," şeklinde açıklıyor
Scebba. "Bunu yapmak için, tüm z/OS görüntülerine System z10 uyumluluğuna
yönelik yazılım yamaları kurduk ve gereksinim duyduğumuzda başka zLinux
katmanları kopyalamakiçin kullanacağımız bir zLinux katmanı kurduk. Ayrıca,
depolama alan ağımıza (SAN) erişimi geliştirmek için IBM DS8300 depolama
sistemini kurduk (önceki işletim depolama alt sistemine ek olarak)."
Scebba ve ekibi, System z10 kurulduktan ve çalışır duruma getirildikten sonra
geçiş projesini üç ayrı aşama şeklinde organize etmiştir. Her proje aşaması,
dağıtılmış UNIX sunucularından zLinux ortamına taşınacak olan ayrı bir
uygulamaya yönelik olarak tasarlanmıştır. Her aşama aynı zamanda, UNIX
uygulamasının zLinux ortamına taşınmasını ve ardından gerçekleştirilecek
kapsamlı testler ile son olarak üretim aşamasına geçişi kapsamaktadır.
Đçeriğin Kanıtlanması ve Projenin Gerçekleştirilmesi
Projenin aynı zamanda gerekçenin kanıtlanması amacıyla gerçekleştirilen ilk
aşaması, kurumsal elektronik posta sistemi olan Lotus Domino 8'in geçişiydi.
Geçiş çok başarılı olmuştur. 1.200 kullanıcının e-posta kutuları, son
kullanıcılara sağlanan hizmette herhangi bir kesinti olmaksızın, iki haftalık bir
süre içinde System z ortamına taşınmıştır.
"Bu başarının ardından, tüm SAP uygulama sunucularımızın geçişini kapsayan
ikinci aşamaya geçtik," şeklinde açıklıyor Scebba. "Veri ambarı sistemi olan SAP
BI daha önce 7.0 sürümüne yükseltilmiş olduğundan, System z'ye önce bu
ortamı taşımaya karar verdik. BI'nın zLinux üzerinde sadece kod olarak
kurulmasının ardından, "stopsap" komutunu kullanarak dağıtılmış UNIX sistemi
üzerinde BI uygulamasını devreden çıkardık ve UNIX sunucusunu kapattık.
Ardından, her UNIX sunucusunun IP adresini System zLinux sunucusunun IP
adresiyle değiştirdik ve bir "startsap" komutu verdik. Bir başka deyişle, kapalı
kalma süresi sadece birkaç dakikaydı."
API'nın, SAP R/3 için dağıtılmış UNIX sunucusu üzerindeki SAP 4.6C
sürümünden System z üzerinde SAP ECC 6.0 sürümüne geçmesi
gerekmekteydi. "Bu işlemin ne kadar süreceği konusunda endişeliydik, bu
nedenle satıcı firmalarımızdan büyütmenin tamamlanması için gerekli olan
kapalı kalma süresine ilişkin tahminler istedik," şeklinde açıklıyor Scebba. "Satıcı
firmalardan aldığımız tahminler, büyütme süreci için 20 saat ve sadece
uygulama sunucusu tarafı için değil, aynı zamanda veriler için açık bir ortam
oluşturulmasına yönelik Unicode kurulumu için de ek 30 saat şeklindeydi. Kendi
sonuçlarımız bizi şaşırttı, çünkü büyütme sadece dokuz saat ve dönüştürme
sadece 12 saat sürdü. Tüm görev bir hafta sonu içinde, herhangi bir kestirme
yola başvurmaksızın tamamlandı."
API BT birimi, SAP geçişini tamamladıktan sonra, üçüncü aşamanın üç
proje etkinliğini aynı anda başlatmıştır:
Hem geliştirme, hem de test ortamları için z/VM kurulumu;
Tüm Tivoli (depolama yönetimi) Identity ve Access Management sunucularının
geçişi; API'nın üretim ortamının karmaşıklığı nedeniyle bu işlem planlanandan iki
ay daha uzun sürmüştür; ve
Ana Veri Yönetimi gereksinimlerinin karşılanması için IBM Infosphere yazılımının
kurulumu.
Yeni altyapının hazırlanmasından ve System z10 sunucusunun kurulmasından,
uygulamaların geçişine ve sistemin ince ayarlarına kadar uçtan uca tüm geçiş
projesi yedi ay sürmüştür. Sonuçlar beklemeye değer olduğunu kanıtlamıştır.
IBM DS8300'ün API depolama ağına eklenmesi, veri erişim süresini yüzde 20
oranında kısaltmıştır. System z10 ortamındaki SAP BI, dağıtılmış UNIX
platformundaki performansına kıyasla yüzde 35 oranında daha kısa işlem süresi
sağlamıştır.
"Proje sırasında, çok sayıda sanal AIX makinesi barındıran iki fiziksel RS/6000
makinesini konsolide ettik," şeklinde açıklıyor Scebba. "Artık tamamen
iyileştirilen yeni System z10 sunucumuz şu şekilde organize edildi: biri üretim ve
biri de test için olmak üzere iki z/OS bölümü var. Bu bölümler yedi DB2 sunucusu
çalıştırıyor. Üretim ortamı için yerel zLinux makinelerimiz var ve uygulamaların
geliştirilmesi ve test edilmesi için konuk z/VM sanal makineleri kullanıyoruz. SAP
tarafından Dağıtılmış Đlişkisel Veritabanı Mimarisi (DRDA) için tek zIIP işlemci
kullanılıyor. Sanal zLinux ortamımız, ERP (Kurumsal Gereksinim Planlama)
işlem sistemi olan ve faturalandırmayı, malzeme yönetimini ve muhasebeyi
kapsayan SAP ECC 6.0'ı çalıştırıyor. Sanal zLinux aynı zamanda veri ambarı ve
kurumsal bilançoların konsolidasyonu için SAP BI 7.0'ı ve kurumsal e-posta
sistemimiz için Lotus Domino 8'i çalıştırıyor. Ana Veri Yönetimi için IBM
Infosphere, müşteri ve tedarikçi, adres ve konum kayıtlarının temizlenmesi için
kullanılırken, tüm kullanıcı kimlik bilgileri için merkezi havuz olarak Tivoli Identity
and Access Management kullanılıyor. Her ikisi de zLinux üzerinde çalıştırılıyor.
Son olarak, zLinux üzerinde, iki adet System z'de yerleşik, yüksek düzeyde
sağlanabilir LDAP (Hafif Dizin Erişimi Đletişim Kuralı) sunucusu kullanıyoruz."
Scebba, geçiş boyunca karşılaştıkları sorunların küçük çaplı olduğunu ifade
etmektedir. "Sadece bir önemli sorunla karşılaştık, bu da posta sunucumuz olan
Lotus Domino ile ilgiliydi," şeklinde açıklıyor. "Sesli posta gereksinimi için Lotus
Domino ile Cisco Unity yazılımlarını bütünleştirmiştik ve sesli posta kutusuna
bırakılan iletiler .wav biçimine dönüştürülerek kullanıcıların e-posta kutularına
yönlendiriliyordu. Maalesef, Domino ile Unity arasındaki bütünleştirme bir IBM
Domino Unity Connection (DUC) ile gerçekleştirilmişti ve bu yazılım sadece
Linux x86 ortamında destekleniyordu. Bu sorunu, sistemi Cisco Unity yazılımını
Lotus Domino yerine Lotus Sametime ile bağlantı kuracak şekilde değiştirerek
aştık. Lotus Sametime bizim anında ileti platformumuz. Bunu yaparak,
kullanıcıların etkilenmesini önlemeyi başardık."
Geçiş Sonuçlarının Değerlendirilmesi
Dağıtılk UNIX sisteminden System z10 sunucusuna geçiş, API için depolama
yönetimini basitleştirmiştir. Hem System z üzerinde yerleşik Linux, hem de IBM
DS8300 kurumsal depolama sistemi üzerindeki System z/VM tabanlı konuk
Linux sistemleri artık API tarafından yönetilebilmektedir. Yerleşik Linux
uygulamaları, geleneksel ana bilgisayar ECKD depolama sistemine erişmek için
Ficon LX fiber kanal bağlantılarını kullanırken, z/VM üzerinde sanallaştırılan
konuk Linux sistemleri SCSI bağlantıları üzerinden DS8300 verilerine erişmek
için anahtarlamalı Ficon SX fiber kanal kullanmaktadır. "Bu iki depolama
yaklaşımı, System z üzerindeki yerleşik ve DS8300 üzerindeki konuk sistemlere
ilişkin tüm gereksinimlerimizi karşıladı," şeklinde açıklıyor Scebba. "Mimarimizin
üçüncü sistem bileşeni halen VMware ESX altında çalışan bir dizi Intel
sunucusundan oluşuyor. Linux on System z altında çalıştırılması mümkün
olmayan Microsoft uygulamaları çalıştırdıkları için bu sunucuların tamamını
sanallaştıramadık. Kritik önem taşıyan ortamlar olmadıkları ve "değerli"
kaynakları bunlara ayırmak istediğimiz için VMware altında çalışan diğer Linux
x86 görüntüleri System z'ye geçirilmedi."
API Oil firmasının sunucu konsolidasyon projesi halen oldukça yeni olsa da,
şirket şimdiden veri merkezinde bazı "çevre dostu" avantajlar elde etmeye
başlamıştır. "Enerji tüketimi yüzde 35 azaldı, fiziksel alan kullanımı yüzde 15
azaldı ve soğutma için daha önce kullanılandan yüzde 65 oranında daha düşük
kapasite kullanılıyor," şeklinde açıklıyor Gaetano Scebba. "BT personelimizin iş
yükü süresi önemli ölçüde değişmedi, ancak gelecekte ürün lisanslarının
maliyetleri açısından avantaj elde edeceğimizi öngörüyoruz. Yeni System z10,
UNIX sunucularımızdan çok daha güçlü. Bu özellik de ek lisanslama
maliyetlerine neden olan işlemci kapasitesi büyütmelerinden kaçınmamıza
olanak sağlayacak."
Sonraki Adımlar
Uygulamaların System z10 üzerindeki yeni Linux ortamına geçirilmesinde elde
edilen başarı, API firmasını gelecekte satın alacağı uygulamalar konusunda
istediği konuma getirmiştir: firma, işi için sınıfının en iyisi olmasının yanı sıra
uygun maliyetli olan uygulamaları satın almasına olanak sağlayacak açık,
rekabetçi bir ortama sahiptir. Bu durum, Teknoloji Müdürü Gaetano Scebba'nın
ekonomiyi daha da geliştirmek ve sonuçların etkinliğini artırmak için kuruluşun
Windows XP masaüstü bilgisayarlarını da System z üzerinde sanallaştırmayı
düşünmesine neden olmuştur. "Amaç, kullanıcılarımıza ister ofiste, ister evde
veya bir müşteri yerinde olsunlar, kendi masaüstlerini kullanma özgürlüğünü
sağlamak," şeklinde açıklıyor Scebba. "Bu proje şu anda tanımlanma
aşamasında ve bu konuya pek çok farklı şekilde yaklaşabileceğimizi biliyoruz...
Burada kritik önem taşıyan husus, artık iş gereksinimlerine ve ekonomik öğelere
bağlı olarak çok sayıda çözüm sağlayıcısını kapsayabilecek bir teknoloji
temeline sahip olmamız. Örneğin, e-posta sunucumuzu ele alalım. Microsoft
Exchange yerine Lotus Domino'yu seçtik, çünkü Domino, Windows ile sınırlı
kalmaksızın çok sayıda platformda çalışabiliyor."