15 Ocak 2018 Pazartesi

Denetime Ramak Kala Bir Gizemin Aydınlatılması

Özellikle son aylarda farklı birçok şirketle oldukça hummalı bir şekilde güvenlik konulu toplantılar ve çalışmalar yapıyoruz. Bunun tek nedeni hiç durmadan ve çeşitli katmanlarda ortaya çıkan donanım ve yazılım açıklarının yanısıra, çeşitli kurumlar tarafından uygulanan harici denetimler ve bu çerçevede ortaya çıkan ihtiyaçlar oluyor. Tabii olarak veritabanları da tüm bu kaosun merkezinde oluyor.

Bakım ve Destek Anlaşması kapsamında danışmanlık hizmeti verdiğim birçok şirkette özellikle son zamanlarda Ernst & Young, KPMG, PWC, PCI gibi uluslararası firmaların yanısıra Finansbank, Abank, TEB, Akbank gibi bankaların çeşitli denetimleri gerçekleşiyor. Yıllardır çok çeşitli kurumlarda, defalarca denetime tabi tutulunca ne zaman, nereden bulgu geleceğini biliyorsunuz. Bu nedenle destek verdiğim ortamlarda varsayılan olarak bu noktalar için zaten gerekli müdahalelerde bulunurum. Fakat bazı tedbirler ancak yeri geldiğinde, gerçekten gerekiyorsa ve yönetimin de desteğiyle alınabiliyor. Örneğin veritabanına gelen işlemlerin kayıt altına alınması gibi. Çünkü bu, ek maliyetler doğurabilecek ve koordinasyon gerektiren bir hamle.

Bir müşterimin geçireceği denetim dolayısıyla Microsoft SQL Server veritabanı ortamındaki bazı kritik tablolarında gerçekleşen kayıt okuma ve değişiklik işlemlerinin kayıt altına alınması gerekiyordu. Yani mesela bir tablodaki kayıt ne zaman, nasıl ve kim tarafından okunmuş veya değiştirilmiş gibi. Bu kapsamda yapılmak istenen kayıt altına alma işleminin hacmi, kapsamı, denetim firmasının ve müşterimin beklentisi, müşterimin ortamı, olanakları ve bütçesi gibi kriterleri değerlendirerek kendilerine bazı tavsiyelerde bulundum. Sonuç itibariyle Microsoft SQL Server'ın önceden başka ortamlarda da (bir banka dahil) kullanmış olduğum bir özelliği olan Database Audit özelliğini kullanmaya karar verdik.

Database Audit özelliğini devreye aldıktan sonra bir şey dikkatimi çekti, SQL cümlecikleri (statement) nedense kırpılmış şekilde kaydediliyordu. Önceden böyle bir durumla hiç karşılaşmamıştım ve buna bir türlü anlam veremedim. 

"statement" alanındaki SQL cümleciği kırpılmış olarak kaydediliyor
Gayet farkındayım ki Windows Application Log dosyasını bu amaçla kullanmak muhteşem bir karar değil; ama Database Audit'in ve diğer benzer mekanizmaların ürettiği kayıtları toplayacak olan uygulamanın bize sunduğu seçeneklerdeki kısırlık nedeniyle Database Audit'in ürettiği kayıtları doğrudan Windows Application Log'una kaydetmek birçok açıdan en mantıklı seçenekti ve ben de bunu uyguladım. Önceki tecrübelerimde Database Audit tarafından üretilen kayıtları doğrudan dosyalara kaydettiğim için ve bir ihtimal yaşadığımız bu sorunun üretilen kayıtların Windows Application Log dosyasına kaydedilmesiyle ilgili olabileceği ihtimaline karşın test etmek için yine bir dosyaya kaydetmeyi de denedim; fakat maalesef sonuç yine aynıydı! SQL cümlecikleri kırpılarak kaydediliyordu.

Testlerden sonra hemen Microsoft'un dokümantasyonunu inceledim ve bu konuda yazılmış olabilecek olası yazıları aradım; fakat konuyla ilgili bir bilgiye ulaşamadım.

Bakım ve Destek Anlaşması kapsamındaki müşterilerimin doğrudan Microsoft ile anlaşması olsun veya olmasın senede 2 defa ücretsiz Microsoft'a çağrı (Case) açılması ve tarafımca bunun takibinin yapılması hakkı da oluyor. Bu kapsamda müşterime bunun belki Database Audit özelliği ile ilgili bir ürün hatası olabileceğini ve dilerlerse Microsoft'a çağrı açabileceğimi söyledim; fakat bunun öncesinde daha hızlı sonuç alabilme ümidiyle şansımı bir de Microsoft'un ilgili forumlarında denemek istedim ve sorumu sorup beklemeye başladım. Bir süre sonra beklediğim cevaplar geldi!

1 günlük bekleyişten sonra gelen cevap ve yanan ampul.

İyiki de sormuşum, hiç Microsoft'un çağrı süreciyle vakit kaybetmeden sağolsun Tom Philips'ten sorunumuzu aydınlatacak cevabı almıştım. Belli ki ilk incelememde dokümantasyondaki ve sorunumun cevabı olan bu kritik bu sayfayı ıskalamışım:

Microsoft dokümantasyonu
Özetlemek gerekirse öncedeki Database Audit tecrübelerimde belli ki hiç 4000 karakteri geçen SQL cümleciğine denk gelmemişim veya dikkatimi çekmemiş ve bu nedenle bu davranışı fark edememişim. Halbuki bu durum Database Audit ile ilgili bir sorun değil, özelliğin doğal çalışma mekanizmasıymış. Bir SQL cümleciği 4000 karakteri geçiyorsa Database Audit bu cümleciği "sequence_no" adı altında artan sayı değeriyle cümleciğin sonuna kadar parçalara bölüyormuş. SQL cümleciğinin tamamını okumak için "event_time", "action_id" ve "session_id" alanlarındaki değerleri takip edebilirmişim. Evet, çok pratik değil; fakat nihayetinde bu bir ürün hatası da değil!

Bu gizemi de aydınlattıktan sonra içimiz rahatladı, çünkü şirketin tabi olacağı denetime çok az bir süre kalmıştı ve sorunumuz için muhakkak bir çözüm üretmemiz gerekiyordu. Eğer bu özelliği zamanında hayata geçiremezsek ve SQL cümleciklerinin bu durumunu denetim firmasına açıklayamazsak bu konuda bulgu çıkabilir ve nahoş sonuçlara neden olabilirdi.

Ekrem Önsoy
Microsoft SQL Server Danışmanı
www.ekremonsoy.com

7 Ocak 2018 Pazar

İş sürekliliği ve şirket imajınıza etkisi

Bu Pazar sabahı neredeyse gün ağarana kadar bakım ve destek anlaşmamız olan çeşitli müşteri ortamlarında Windows güncellemeleri uyguladık. Bu Microsoft SQL Server ortamlarının bazılarında iş sürekliliğini sağlayan Always On Availability Groups veya Failover Clustering gibi teknolojiler kullanılırken, bazıları ise "Stand-alone" tabir edilen, yani iş sürekliliği olmayan ortamlardı.

İş sürekliliği altyapısı olan ortamlardaki Windows güncellemelerinden kaynaklanan kesinti süreleri ortalama 5-8 saniye ile sonlanırken, iş sürekliliği olmayan ortamlarda bu süre 5-10 dakikalara kadar çıktı. İş sürekliliği olmayan ortamlar için bu nispeten belirsiz bir süre, çünkü güncellemeden kaynaklı çıkabilecek olası bir sorun, böyle bir ortamdaki kesinti süresini çok daha fazla uzatabilir. Halbuki iş sürekliliği olan bir ortamda güncellemeler önce pasif olan sunucularda uygulandığı için herhangi bir aksilik güncellemeler henüz canlı sisteme uygulanmadan büyük ihtimalle fark edilir. Gerekiyorsa pasif olan sunucu tamamen yeniden kurulabilir, ama sonuç itibariyle doğru kurgulanmış bir canlı sistemde herhangi bir kesinti oluşmadan sorun atlatılmış olur.

Peki iş sürekliliği kimler için gerekli? Bugüne kadar birçok sektörden birçok şirketle çalışma şansı buldum ve gördüm ki, iş sürekliliği "şu sektörler için olmazsa olmaz, bu sektörler için olmasa da olur" denilerek genelleme yapılabilecek bir konu değil. Örneğin bazı sağlık veya finans kurumları 7/24 hizmet verirken, bazıları 5/8 hizmet verebiliyor. İş sürekliliği, bir şirketin verdiği hizmetler ve hedefleri kapsamında seçilebilecek bir yöntem. Bununla birlikte, eğer bir şirket 7/24 hizmet veriyorsa iş sürekliliğini muhakkak ciddiye almalıdır diye düşünüyorum.

Mesela küçük bir test yapalım. IT veya Sistem Yöneticisi olarak yönetiminizde olan veritabanı ortamlarınız için şu sorulara nasıl yanıt verirdiniz? 



"Tahammül edebileceğiniz en uzun veritabanı kesinti süresi nedir?"

"Canlı veritabanı ortamınızdaki olası bir sorun/kesinti hakkında son kullanıcılar tarafından mı haberdar ediliyorsunuz?"

"Canlı veritabanı ortamınızda bir kesinti oluşması durumunda, veritabanlarınızı en kısa ne kadar sürede tekrar çalışır duruma getirebilirsiniz?"


Tabii ki bu konudaki sorular bunlarla sınırlı değil, hatta bunlar sadece bir başlangıç; ama iyi bir başlangıç.

İş sürekliliğinden ayrı olarak bu sabahki çalışma kapsamında kesinti yaşanan ortamların bazılarında kesinti nedeniyle alınan hataların doğrudan son kullanıcıya yansıtıldığını gördüm. Bir son kullanıcı gözüyle böyle bir durumun bir şirketin imajı açısından hiç de hoş olmadığını düşünüyorum. Bir profesyonel gözüyle de veritabanı ile ilgili hataların doğrudan son kullanıcılara ve potansiyel saldırganlara alenen ifşa edilmesini güvenlik açısından hiç doğru bulmuyorum. Bu sorun, iş sürekliliği olsun veya olmasın her halükarda gerçekleşebiliyor. Tabii iş sürekliliği olan ortamlarda bu sorun birkaç saniye sürerken, diğer ortamlarda uzun dakikalar boyunca sürebiliyor.

İş sürekliliği şansa bırakılacak kadar ucuz bir konu değil. Bazı ortamlardaki 10 dakikalık kesintinin sadece maddi bedeli dudak uçuklatacak kadar yüklü olabiliyor.

Az kesintili, bol huzurlu günler dilerim.

Ekrem Önsoy
Microsoft SQL Server Danışmanı
www.ekremonsoy.com

5 Aralık 2017 Salı

Kim korkar kritik bir ayarı değiştirmekten? (İpucu: temkinli olmakta fayda var)

Birkaç ay önce sahadaki sağlık kontrolü çalışmalarım sırasında karşılaştığım sorunlardan birini bu yazı ile anlatmıştım. Bu duruma benzer bir sorunun geçenlerde başka bir ortamda yaşandığına şahit oldum.

Sorun oluştuğunda SQL Server Management Studio ve uygulamalar ile SQL Server Instance'ına bağlanmaya çalıştığımızda şöyle hatalar oluşuyordu:

"A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 0 - The specified network name is no longer available.) (Microsoft SQL Server, Error: 64)"

Açıkçası özellikle aşina olmayanlar için oldukça kafa karıştırıcı bir mesaj. Hata mesajını özetle ve mealen şöyle Türkçeye çevirebiliriz "Sunucuya bağlantı sağlandı, ama sonra bir hata oluştu (Belirtilen ağ adı artık ulaşılabilir değil)". Yani sunucuya ulaşabiliyoruz, ama sonra bir hata oluşuyor ve birden sunucu ulaşılamaz oluyor. 

Not: SQL Server'da buna çok benzer, fakat farklı ibareler içeren çeşitli hata mesajlarıyla karşılaşılabilir. Birebir aynı olmadığı sürece sorunları birbirine karıştırmamakta fayda var. SQL Server bağlantı sorunlarıyla ilgili daha fazla bilgi için referans yazımı bu adresten inceleyebilirsiniz. Ayrıca Aaron Bertrand'tan 18456 hatalarıyla ilgili güzel bir referans yazısını da bu adreste bulabilirsiniz.

Sorun anında yeni oturum açmak pek mümkün olmadığı için varolan açık oturumları kullandık ve hata kayıtlarını kontrol ettiğimizde şu hataları gördük:

"Could not connect because the maximum number of user connections has already been reached."

SQL Server'da normal şartlar altında, yani varsayılan olarak "User Connection" ayarı sınırsızdır, daha doğrusu 0'dır ve bu da 32.767'ye karşılık gelir. 

Not: Tabii ki 32.767 nihayetinde bir sınırdır, ama pratikte bu sınıra ulaşmanız pek kolay değil.

Not: Benzer sıkıntılı durumlarda Dedicated Administrator Connection (DAC) hayat kurtarır. Her SQL Server veritabanı yöneticisi muhakkak bu kavramı ve ne zaman, nasıl kullanılabileceğini bilmelidir.

Sanırım şimdiye kadar birçoğunuz durumu anlamıştır. "User Connection" ayarı çok daha küçük bir sayı ile değiştirilmiş. Her ortamda "lütfen bilmediğiniz, emin olmadığınız, yeterince test etmediğiniz ayarı değiştirmeyin" diye bas bas bağırıyoruz; ama "tarih tekerrürden ibarettir" sözü, anlamı gibi kendini de tekrar ettirip duruyor.

Sonradan öğrendiğime göre bu değişikliğe neden olan motivasyon, sunucunun zaten X sayısından fazla kullanıcı bağlantısını kaldıramayacağı düşüncesiymiş. Fakat bu senaryoda yanılınan temel nokta şu oldu bence, bağlantılar aktif olsun, pasif olsun, bu ayar her türlü bağlantıyı kapsar. Örneğin sorun esnasında kontrol ettiğimde varolan bağlantıların %80'i pasifti (sleeping) ve ancak %20'si aktif, çalışan bağlantıydı. Bu normal mi, anormal mi ayrı bir tartışma konusu; ama bu kullanıcı bağlantı sayısı kesinlikle sunucunun kaldırabileceğinin çok altındaydı. Yani eğer bu ayar bu şekilde suni olarak değiştirilmeseydi, bu durumdan kaynaklanan bir kesinti olmayacaktı. Sonuç itibariyle elbette her sunucu kaynağının ve sistemin kaldırabileceği bir yük var, ama buna suni olarak ve yeterince ince eleyip sık dokumadan müdahale etmeye ne gerek var?

Not: Özellikle kompleks sistemlerde türlü anormallikler, beklenmedik durumlar muhakkak, olacaktır (dikkat "olabilir" demiyorum); sunucularımızın ayarları ve donanım kaynakları özellikle kritik ortamlarda bu tür anormallikleri ve anormal yükleri kaldırabilecek şekilde düşünülmeli ve tasarlanmalıdır. 

Sistemin sağlığını etkileyebilecek benzer değişiklikler yapılmadan önce bu değişikliklerin olası sonuçları, özellikle çok kritik canlı sistemlerde muhakkak etraflıca düşünülmelidir. Ayarlar, kavramlar ve özellikler hakkında resmi dokümantasyon ve ilgili değişikliği uygulamış insanların gerçek hayat tecrübeleri muhakkak dikkate alınmalı, incelenmeli, okunmalı ve dinlenmelidir. Ayrıca böyle değişiklikleri canlı ortamınızda uygulamadan önce kendi ortamınız için testler ve gözlemler yapmanızda büyük fayda var. Değişiklik öncesinde (yeterli bir süre boyunca) ne durumda olduğunuzu, değişiklik sonrasında hangi duruma geldiğinizi, metriklerin nasıl ve ne yönde değiştiğini mutlaka bilmelisiniz. Bunları bilmezseniz, yönetemezsiniz. Yönetemediğinizde de durum kontrolden çıkar.

Ekrem Önsoy
Microsoft SQL Server Danışmanı
www.ekremonsoy.com

27 Kasım 2017 Pazartesi

Hata: Servis hesabının Always On Availability Groups kurulumuna etkisi

Geçen gün bir müşterimde Always On Availability Groups kurulumu yaparken önceden karşılaşmadığım bir sorun ile karşılaştım. Müsait olunca konu hakkında bir blog yazısı yazarım diye o anda ekran görüntüsünü almıştım. Soruna dair ilgili ekran görüntüsünü aşağıda paylaşıyorum.

Kurulum yaparken karşılaştığım sorun

Bilgi mesajı şöyle diyordu:
"The Endpoints tab lists at least one endpoint that uses only Windows Authentication. However, the server instance might be running under a nondomain account. To use the listed endpoint, change the corresponding SQL Server service account to a domain account. To continue using the nondomain account, after the endpoint to use a certificate."

SQL Server bir nedenden dolayı Replica'lardan birinin Domain hesabıyla çalışmadığını düşünüyordu. Fakat "SQL Server Service Account" sütununda da görülebileceği üzere iki hesap da Domain hesabı. Kuruluma bu şekilde devam ettiğimde kurulum bir türlü tamamlanmıyordu. Bir hata da vermiyordu veya verinceye kadar bekleyememiştim, ama bir yerlerde sıkıntı olduğu artık çok netti.

Kurulumu sadece arayüzle değil, T-SQL ile denediğimde de aynı sonuç ile karşılaşıyordum. Yukarıdaki bilgi mesajı gelmiyordu, ama kurulum da tamamlanmıyordu.

Endpoint'leri de kontrol etmiştim, herhangi bir anormallik yoktu.

Yukarıdaki ekran görüntüsündeki gibi farklılıkları oldum olası hiç sevmem. Yani örneğin Replica'lardan birinin servis hesabı "servis_hesap_adi@domain_adi" biçimindeyken diğerininkinin "domain_adi\servis_hesap_adi" olması benim için rahatsız edici bir durum. O anda tabii ki sorunun nedeninin bu olduğundan %100 emin olmasam da, %90'lık çok güçlü bir tahminle sorunun bu olacağını düşünmüştüm. 

Sonra test etmek için bir SQL Server kurulu sunucuda SQL Server Configuration Manager kullanarak 2. Replikanın servis hesabınının biçimini de canlı sunucudaki gibi "servis_hesap_adi@domain_adi" olarak değiştirmek istedim ve bunun yapılamadığını gördüm. Yani istesem de SQL Server Configuration Manager ile bir servis hesabını bu yazım biçimiyle atayamıyordum. O anda anladım ki birisi bu hesap değişikliğini SQL Server Configuration Manager yerine Services.msc ile yapmıştı, ki bu hiç iyi bir pratik değildir. Tüm SQL Server servis hesabı değişikliği işlemlerini SQL Server Configuration Manager aracıyla yapmalısınız. Çünkü bu sırada sadece servis hesabı değiştirilmez, aynı zamanda bu hesaba arkaplanda gerekli bazı yetkiler ve rol üyelikleri uygulanır. Eğer bu işi Services.msc ile yaparsanız sadece servis hesabı değişmiş olur. Ayrıca bu örnekte de görülebileceği üzere SQL Server servis hesabı değişikliğini "domain_adi\servis_hesap_adi" yerine "servis_hesap_adi@domain_adi" biçimiyle yapmış olabilirsiniz, ki bu örnekten de görülebileceği gibi bu biçimi kullanmak ilginç sorunlara neden olabiliyor.

Not: Bu noktada bir belirsizliğe dikkat çekmek istiyorum. Bu yazıya konu olan sorun SQL Server servis hesabının SQL Server Configuration Manager yerine Services.msc'den değiştirilmesinden de kaynaklanıyor olabilir, servis hesabının "domain_adi\servis_hesap_adi" biçimi yerine "servis_hesap_adi@domain_adi" biçimiyle belirlenmiş olmasından da kaynaklanıyor olabilir. Örneğin SQL Server servis hesabını Services.msc'den değiştirip, bu işlemi yaparken de "domain_adi\servis_hesap_adi" biçimini kullansaydım da sorun çözülebilirdi belki? Bu, ayrı bir test gerektiriyor. Ortam canlı olduğu için o anda bunun testini yapamadım. Eğer başka bir ortamda bunu test edebilirsem bu yazıyı güncelleyeceğim.

Servis hesabı değişimi (normal şartlar altında) kısa da olsa kesinti gerektiren bir değişiklik. İlgili yöneticilerle planlı bir kesinti için anlaştık ve zamanı geldiğinde canlı sunucudaki SQL Server Database Engine servis hesabını SQL Server Configuration Manager kullanarak ve "domain_adi\servis_hesap_adi" biçiminde değiştirdim. Bu değişiklikten sonra Always On Availability Groups kurulumunu tekrar denedim ve yukarıda paylaştığım ekran görüntüsündeki hata ile karşılaşmadım.

Yukarıdaki bilgi mesajıyla karşılaşmadığım gibi kuruluma devam ettikten sonra da kurulumun başarıyla tamamlandığını gördüm. Yani bu değişiklikle sorunum çözüldü. Olur da bir gün başka bir arkadaşım karşılaşırsa diye paylaşmak istedim.

Ekrem Önsoy
Microsoft SQL Server Danışmanı


3 Kasım 2017 Cuma

Firmam 2. yaşını doldurdu, kutlu olsun!

Firmamı kuralı 2 sene oldu ve bu vesileyle bir teşekkür yazısı yazmak istedim.

2 sene önce sevgili dostum Yiğit Aktan'ın (t) da kışkırtmalarıyla artık kendi firmamı kurmam kaçınılmaz olmuştu. Ben de kaçınmadım, üşenmedim ve uzun yıllardır aşkla kullandığım, inciğine, cıncığına kadar kurcaladığım, hakkında sabah akşam okuyup dersler aldığım, sınavlarına girip, ödül kazandığım Microsoft SQL Server ürünü konusunda profesyonel danışmanlık hizmeti vermeyi hedeflediğim firmamı kurdum.


www.ekremonsoy.com adresindeki ilk yazım

Firmamı kurduğumdan beri sağolsun sevgili eşim başta olmak üzere, dostlar ve piyasanın çeşitli uç ve bucağına dağılmış olan eski iş arkadaşlarım desteklerini hiç esirgemediler. Bu süreçte bazılarıyla yollarımız farklı firmalarda tekrar kesişti, bazılarıyla tekrar birlikte çalışma fırsatımız oldu.

Bu 2 yıllık süreçte İzmir'deki bir matbaadan, Bursa'daki bir girişimciden, dünya çapında binlerce insan çalıştıran şirketlere kadar birçok şirket ile çalışma fırsatım oldu. Aşağıda, hala birçoğuyla çalıştığımız bu şirketlerin bazılarının isimlerini (alfabetik) paylaşmaktan memnuniyet duyuyor ve bana güvenip, benimle çalıştıkları için teşekkür ediyorum.

- Ada Yazılım
- Alp Havacılık
- Borusan Lojistik
- Doğa Sigorta
- Edenred Türkiye
- Ericsson
- Morhipo.com
- Papara
- Penta
- Pronet
- RND
- Tiposoft

Her geçen gün öğrendiğim yeni şeyleri 20 yılın tecrübesiyle ve ilk günkü hevesle uygulayıp, paylaşma fırsatı bulduğum için ve yetmezmiş gibi bir de bu sayede faturalarımı ödeyebildiğim için çok müteşekkirim, hayata ve katkısı olan herkese.

Ekrem Önsoy
Microsoft SQL Server Danışmanı
www.ekremonsoy.com