Ubuntu kullananlara bir uyarı, bir yere ssh komutunu yazdıktan sonra anlamsız bir süre bekledikten sonra şifre ekranı geliyorsa şunu yaparak bu durumdan kurtulabilrisiniz;
/etc/nsswitch.conf dosyasını açın, içinde hosts olan satırın değerini:
hosts: files dns
olarak değiştirin ve hayatınıza devam edin…
Sunucudaki disk azalma sorunu sık rastlanan bir durum. Gayır gayır log basıp duruyoruz eh onun bir de götürüsü var, disk gibi. Linux işletim sisteminde konsol üzerinden hangi dizinin ne kadar yer kapladığını tespit etmek için kompleks bir tanım var, bunu buraya yazayım ki lazım olan kullansın:
alias duf='du -sk * | sort -n | perl -ne '\''($s,$f)=split(m{\t});for (qw(K M G)) {if($s<1024) {printf("%.1f",$s);print "$_\t$f"; last};$s=$s/1024}'\'
böylece duf diyerek içinde bulunduğunuz dizinin altındaki dizinlerin kapladığı alanı görebiliyoruz. Hatta şurda buldum:
http://www.earthinfo.org/linux-disk-usage-sorted-by-size-and-human-readable/
Sonradan bir de şunu buldum: du -skh *
Open Solaris ile ilgili yaşanabilecek temel problemlerin çözümlerini içeren güzel bir yazı:
http://www.dedoimedo.com/computers/opensolaris-2008-11.html
Ölçeklenebilirlik (Scalability) konusunu zor yollardan öğrenmiş Steffen Konerow isimli şahsın yazdığı güzel bir yazı buldum. Yazıda 1 milyon kullanıcının ziyaret ettiği bir web uygulamasının nasıl çöktüğü, çöküşe engel olabilmek için neler yaptıkları ve hatalarını çok güzel anlatmış. Ben de elimin altında bulunsun diye bu 6 maddeyi yazayım dedim. (Bize soraydı biz de yardım ederdik heheh)
1. Dosyaları ağ üzerindeki bir alanda tutun ve sunucunuz ölsün. (Lokal diskte tutun ya da çok erişilen dosyaları hafızada (ramdisk) tutun.)
2. Web sunucunuzun ayarlarıyla oynamayın direkt kurup kullanın ve sunucunuz ölsün. (Sunucusu ayarlarında optimizasyon yapın, daha performanslı web sunucuları (ngix gibi) tercih edin.)
3. Tek bir veritabanı sizi sonsuza kadar idare eder diye düşünün ve sunucunuz ölsün. (En güçlü veritabanı sunucunun bile bir limiti vardır. Limitlere ulaşmadan master-slave yapısı ya da cluster yapısına geçin.)
4. Sunucu yavaşlayınca daha iyisini alırım diyin ve sunucunuz ölsün. (Daha fazla donanıma para harcamak yerine açık kaynaklı yazılımları araştırın, mesela memcached gibi. Doğru cache’leme ile veritabanınızı rahatlatabilirsiniz.)
5. Bütün dosyaları tek bir dizinde tutun ve sunucunuz ölsün. (Çok sayıda dosyayı tek bir dizinde tutmayın, dosyaları farklı klasörlere yayın ya da farklı dosya sistemleri (ReiserFS vs) deneyin.)
6. Tamam artık süper çalışıyor daha fazla geliştirmeye gerek yok diyin ve sunucunuz ölsün (Geliştirmeyi hiç bırakmayın, sürekli öğrenin, araştırın.)
Yazının tamamı şurda: http://highscalability.com/blog/2010/8/23/6-ways-to-kill-your-servers-learning-how-to-scale-the-hard-w.html
Efendim diyelim ki bir pool’unuz ve bunun içinde sunucularınız var ve siz bir sunucuyu bu pool’dan çıkartmak istiyorsunuz. Fakat sistem erişiminiz olmadığı için istekleri dağıtan mekanizmaya erişemiyorsunuz. Bunun için ben pool dışında bırakmak istediğim sunucudaki tomcat’i durdurup port’unu değiştirip tekrar açmıştım. Gayet güzel çalıştı fakat tomcat değil de misal jboss kullanıyo olsaydım bu işi afedersiniz bok yapardım. Çünkü jboss’un çalıştığı port’u değiştirmek için 88 tane yerde değişiklik yapılması gerekiyor.
Velhasıl ip değiştirmeden de bu işi sunucunun üzerindeki firewall’u kullanarak yapabiliyormuşuz. Bu yöntem ip değiştirmekten çok daha güzel. Şöyle oluyormuş:
iptables -t filter -I INPUT 1 -p tcp -s ! 192.168.1.0/24 --dport 8080 -j DROP
Buradaki 192.168.1.0/24 kısmı olmaz ise siz de o porttan erişemiyor oluyorsunuz. Dolayısı ile buraya kendi ip bloğunuzu girdiğiniz zaman siz hariç kimse bu port’tan bu sunucuya erişemiyor oluyor. Haliyle dağıtıcı uygulama da sunucu kapalı zannedip pool’dan çıkartıyor. Siz güzel güzel işinizi yapıyorsunuz. İşiniz bitince de
iptables -F
diyerek yaptığınız filtrelemeyi kaldırıyorsunuz.
(Serhat’a teşekkürler…)