Veritabanının ve web sunucusunun aynı makinede olması neden tavsiye edilmez?

Scott Hanselman'ın Stack Overflow ekibiyle ( bölüm 1 ve 2 ) röportajını dinlerken, SQL sunucusu ve uygulama sunucusunun ayrı makinelerde olması gerektiği konusunda kararlıydı. Bu sadece bir sunucunun güvenliği ihlal edildiğinde her iki sistemin de erişilebilir olmadığından emin olmak için mi? Özellikle hiçbir parçanın çok fazla CPU veya bellek kullanmadığı küçük bir uygulama için, güvenlik endişeleri iki sunucunun karmaşıklığından (ekstra maliyet, ikisi arasında özel ağ bağlantısı, daha fazla bakım, vb.) Ağır mı basıyor? Bir sunucunun güvenliği ihlal edilmiş iki sunucuda bile, bir saldırgan, veritabanını silerek veya uygulama koduyla uğraşarak ciddi zararlar verebilir.

Performans bir sorun değilse, bu neden bu kadar önemli?

1. Güvenlik. Web sunucunuz, halka açık internetten erişilebilen ve anonim kullanıcılardan güvenilmeyen girdiler alan bir DMZ'de yaşıyor. Web sunucunuzun güvenliği ihlal edilirse ve DB'nize bağlanırken en az ayrıcalık kurallarına uyarsanız, maksimum maruz kalma, uygulamanızın veritabanı API'si aracılığıyla yapabileceği şeydir. Arada bir iş katmanınız varsa, saldırganınız ile verileriniz arasında bir adım daha vardır. Öte yandan, veritabanınız aynı sunucu üzerindeyse, saldırgan artık verilerinize ve sunucunuza root erişimine sahiptir.
2. Ölçeklenebilirlik. Web sunucunuzu durumsuz tutmak, web sunucularınızı yatay olarak zahmetsizce neredeyse tamamen ölçeklendirmenize olanak tanır. Öyle çok yatay bir veritabanı sunucusu ölçekli zor.
3. Verim. 2 kutu = 2 kat CPU, 2 kat RAM ve disk erişimi için 2 kat mil.

Tüm söylenenler, bu noktaların hiçbirinin gerçekten önemli olmadığı makul durumları kesinlikle görebiliyorum.

Gerçekten önemli değil (sitenizi aynı makinede web / veritabanı ile mutlu bir şekilde çalıştırabilirsiniz), ölçeklendirmenin en kolay adımıdır ..

StackOverflow'un yaptığı tam olarak buydu - IIS / SQL Server çalıştıran tek makineden başlayarak, ağır bir şekilde yüklenmeye başladığında, ikinci bir sunucu satın alındı ​​ve SQL sunucusu buna taşındı.

Performans bir sorun değilse, iki sunucu satın almak / bakımını yapmak için para harcamayın.

Öte yandan, farklı bir blog yazarı olan Scott'a (Watermasyck, Telligent'ten) atıfta bulunarak - çoğu kullanıcının, veritabanını web sitesiyle aynı makineye koyarak web sitelerini (Telligent'in Topluluk Sunucusunu kullanarak) hızlandırabileceğini buldular. Bununla birlikte, müşterilerinin durumunda, genellikle db & web sunucusu bu makinedeki tek uygulamalardır ve web sitesi makineyi o kadar zorlamaz. Ardından, ağ üzerinden veri göndermek zorunda kalmama verimliliği, artan gerilimi fazlasıyla telafi etti.

Büyük faktörün performans olacağını düşünürdüm. Hem web sunucusu / uygulama kodu hem de SQL Server, yaygın olarak istenen verileri bellekte önbelleğe alır ve bunları aynı bellek alanında çalıştırarak önbellek performansınızı düşürürsünüz.

Tom bu konuda haklı. Diğer bazı nedenler, uygun maliyetli olmaması ve ek güvenlik riskleri olmasıdır.

Web sunucularının veritabanı sunucularından farklı donanım gereksinimleri vardır. Veritabanı sunucuları, çok fazla bellek ve gerçekten hızlı bir disk dizisiyle daha iyi performans gösterirken, web sunucuları yalnızca dosyaları ve sık veritabanı isteklerini (kurulumunuza bağlı olarak) önbelleğe almak için yeterli bellek gerektirir. Maliyet etkinliği ile ilgili olarak, iki sunucu mutlaka daha ucuz olmayacaktır, ancak kaynaklar için rekabet eden farklı uygulamalara gerek kalmadığından performans / maliyet oranı daha yüksek olmalıdır. Bu nedenle, her ikisine de hitap eden ve 2 özel sunucuya eşdeğer performans sunan bir sunucu için muhtemelen çok daha fazla harcamak zorunda kalacaksınız.

Güvenlik kaygısı, tek makinenin güvenliği ihlal edilirse, hem web sunucusunun hem de veritabanının savunmasız olmasıdır. İki sunucu ile, 2. sunucu hala güvende olacağından (en azından bir süre için) biraz nefes alanınız var.

Ayrıca, bir grup farklı web uygulaması tarafından kullanılan yalnızca birkaç veritabanı sunucusuna sahip olmanız gerekebileceğinden, bazı ölçeklenebilirlik avantajları vardır. Bu şekilde, yükseltmeleri veya yamaları uygulamak ve performans ayarı yapmak için daha az işiniz olur. Yine de bu görevleri kolaylaştırmak için sunucu yönetim araçları olduğuna inanıyorum (tek makine durumunda).

Güvenlik büyük bir endişe kaynağıdır. İdeal olarak veritabanı sunucunuz, yalnızca veri erişimini gerçekleştirmek için gereken bağlantı noktalarının açık olduğu bir güvenlik duvarının arkasında oturmalıdır. Web uygulamanız, veritabanı sunucusuna, uygulamanın çalışması için yeterli haklara sahip olan ve daha fazlasını içermeyen bir SQL hesabıyla bağlanmalıdır. Örneğin, nesnelerin düşmesine izin veren hakları kaldırmalısınız ve kesinlikle 'sa' gibi hesapları kullanarak bağlanmamalısınız.

Web sunucusunu bir ele geçirme nedeniyle kaybetmeniz durumunda (yani, yönetici haklarına tam gelişmiş bir ayrıcalık yükseltme), en kötü durum senaryosu uygulamanızın veritabanının tehlikeye atılması, ancak tüm veritabanı sunucusunun tehlikeye atılmamasıdır ( veritabanı sunucusu ve web sunucusu aynı makineydi). Veritabanı bağlantı dizelerinizi şifrelediyseniz ve bilgisayar korsanı bunların şifresini çözecek kadar bilgili değilse, kaybettiğiniz tek şey web sunucusudur.

Henüz bahsedilmeyen bir faktör yük dengelemedir. Web sunucusunu ve veritabanını ayrı makineler olarak düşünmeye başlarsanız, daha az ağ gidiş-dönüşü için optimizasyon yaparsınız ve ayrıca ihtiyaçlar arttıkça ikinci bir web sunucusu veya ikinci bir veritabanı motoru eklemek daha kolay hale gelir.

İlk elden deneyimlerime dayanarak, web sunucusunu ve veritabanını farklı makinelere yerleştirmenin genellikle iyi bir fikir olduğunu söyleyebilirim. Kaynak yoğun bir uygulamanız varsa, makinedeki CPU döngülerinin zirveye çıkmasına ve dolayısıyla makinenin durmasına neden olabilir. Bununla birlikte, uygulamanızın veritabanını sınırlı olarak kullanması durumunda, bunların bir sunucuyu paylaşması büyük olasılıkla önemli olmayacaktır.

Vay canına, hiç kimse SQL sunucusunu 5k dolara satın alırsanız, onu web uygulamanızdan daha fazlası için kullanmak isteyebileceğiniz gerçeğini ortaya koymaz. Express kullanıyorsanız, belki umursamıyorsunuzdur. SQL sunucularının 20 ila 30 uygulama için Veritabanları çalıştırdığını görüyorum, bu yüzden onu web sunucusuna koymak akıllıca olmaz.

İkincisi, sunucunun kimin için olduğuna bağlıdır. Finans şirketleri ve hükümet için çalışıyorum. Bu yüzden, sadece sprocs kullanma ve web sunucusundan SQL'e bağlantı noktalarını sınırlama yaklaşımında çılgınca bir acı kullanıyoruz. Yani web uygulaması saldırıya uğrarsa. Bilgisayar korsanının yapabileceği tek şey, web sunucusundaki kullanıcı hesabı, yalnızca DB üzerindeki sprocs'u görmek / çağırmak için kilitlendiğinden sprocs'u çağırmaktır. Şimdi bilgisayar korsanı DB'ye nasıl girileceğini bulmalı. Web sunucusundaysa, ulaşılması kolaydır.

Daniel Earwicker'a katılıyorum - güvenlik sorusu oldukça kusurlu.

Bir web sunucusuyla tek bir kutu kurulumunuz varsa ve yalnızca bu web sunucusu için veritabanı varsa, bu web sunucusu tehlikeye atılırsa hem web sunucusunu hem de yalnızca o belirli uygulama için veritabanını kaybedersiniz.

Bu, 2 sunuculu bir kurulumda web sunucusunu kaybederseniz olanla tamamen aynıdır. Web sunucusunu ve yalnızca o belirli uygulamanın veritabanını kaybedersiniz.

2 sunuculu bir kurulumunuz olduğunda 'DB sunucusunun bütünlüğünün geri kalanı korunur' argümanı ilgisizdir, çünkü ilk senaryoda, diğer tüm uygulamalarla (varsa) ilgili diğer tüm veritabanı sunucuları da etkilenmeden kalır. - oldukları gibi, başka bir yerde barındırılıyor.

Benzer şekilde, Kev'in sorduğu soruya 'DB sunucusunda bulunan diğer tüm veritabanları ne olacak? Tek kaybettiğiniz tek bir veritabanı. '

• Bir uygulamayı ve veritabanını tek bir sunucuda barındırıyorsanız, yalnızca o uygulamayla ilgili olan veritabanlarını o sunucuda barındırırsınız. Bu nedenle, çoklu sunucu kurulumuna kıyasla tek bir sunucu kurulumunda herhangi bir ek veritabanını kaybetmezsiniz.

Bunun tersine, saldırganın Web Sunucusuna erişiminin olduğu 2 sunucu kurulumunda ve proxy aracılığıyla veritabanı sunucusuna sınırlı haklar (en iyi durumda), diğer tüm uygulamaların veritabanlarını riske atabilirler. yavaş, bellek yoğun sorgular veya veritabanı sunucusundaki kullanılabilir depolama alanını en üst düzeye çıkarma. Uygulamaları sanallaştırma gibi kendi endişelerine ayırarak, güvenlik amaçları için de olumlu bir şekilde izole etmiş olursunuz.

Uygulamaya ve amaca bağlıdır. Yüksek kullanılabilirlik ve performans kritik olmadığında, DB ile web sunucusunu ayırmamak fena olmaz. Özellikle performans kazanımları göz önüne alındığında - uygulama büyük miktarda veritabanı sorgusu yaparsa, yanıt sürelerini düşük tutarak önemli miktarda ağ yükü, hepsini aynı sistemde tutarak kaldırılabilir.

Bunun nedeni, iki makinenin genellikle farklı şekillerde optimize edilmesi gerektiğidir. Bunun dışında hiçbir fikrim yok, tüm uygulamalarımızı aynı makinede sunucu veritabanıyla çalıştırıyoruz - herkese açık olmadığımız kabul edilir - ancak hiçbir sorun yaşamadık.

Çok fazla insanın, bir makinenin her ikisinden de ödün verilmesini önemsediğini hayal edemiyorum, çünkü web uygulaması genellikle veritabanındaki şema olmasa bile, en azından verilere neredeyse sınırsız erişime sahip olacaktır.

Başkalarının ne söyleyebileceğiyle ilgileniyor.

O podcast'i dinledim ve eğlenceliydi ama güvenlik argümanı bana mantıklı gelmedi. Sunucu A'nın güvenliğini ihlal ettiyseniz ve bu sunucu B sunucusundaki verilere erişebiliyorsa, anında B sunucusundaki verilere erişebilirsiniz.

Veritabanı lisansları ucuz değildir ve genellikle CPU başına ücretlendirilir, bu nedenle web sunucularınızı ayırarak veritabanı lisanslarınızın maliyetini azaltabilirsiniz.

Örneğin, 8 CPU içeren hem web hem de veritabanı yapan 1 sunucunuz varsa, 8 cpu lisansı için ödeme yapmanız gerekecektir. Ancak, her biri 4 CPU'lu iki sunucunuz varsa ve veritabanını bir sunucuda çalıştırıyorsanız, yalnızca 4 cpu lisansı için ödeme yapmanız gerekecektir.

Ek bir endişe de, veritabanlarının tüm kullanılabilir hafızayı alıp kullanmak istediği zaman yedek olarak tutmayı sevmesidir. Belleği sınırlandırmaya zorlayabilirsiniz, ancak bu, veri erişimini önemli ölçüde yavaşlatabilir.

Bir web sunucusunda bir veritabanı sunucusu çalıştırmanın gerçek bir performans kazanımı olduğunu iddia etmek hatalı bir argümandır.

Veritabanı sunucuları sorgu dizelerini alıp sonuç kümelerini döndürdüğünden, veri sunucusundan web sunucusuna gerçekten akan veriler nispeten küçüktür, ancak sorguyu işlemek ve sonuç kümesini oluşturmak için gereken beygir gücü nispeten büyüktür. Bu nedenle, veri aktarım süresi civarında performansı optimize etmek, yanlış şey etrafında optimize etmektir.

Güvenlik ile ilgili olarak, veri sunucusunun web sunucusundan farklı bir kutuda olmasının avantajları vardır. Böyle bir düzene sahip olmak, güvenliğin tamamı ve sonu değildir, ancak doğru yönde atılmış bir adımdır.

Ölçeklenebilirlikle ilgili olarak, artan trafiği idare etmek için web sunucuları eklemek ve bunları kümeye koymak kolay ve nispeten ucuzdur. Veri sunucuları eklemek ve bunları kümelemek o kadar kolay ve ucuz değil. Ayrıca, web sunucuları ve veri sunucularının farklı donanım gereksinimleri vardır, bu nedenle birden çok kutu ölçeklenebilirliğe yardımcı olur.

Küçükten başlıyorsanız ve yalnızca bir kutunuz varsa, o zaman iyi bir yol sanal makineleri kullanmak olacaktır. Web sunucusunu ve veri sunucusunu tek bir ana bilgisayarda farklı sanal makinelerde çalıştırmak, tek bir büyük kutu fiyatı karşılığında size ayrı kutuların tüm kazançlarını sağlar.

İşletim sistemi başka bir husustur. Veritabanınız daha büyük bellek alanlarına ve dolayısıyla UNIX'e ihtiyaç duyabilirken, web sunucunuz - veya daha spesifik olarak, yalnızca iki katmandan bahsettiğiniz için uygulama sunucunuz - .Net tabanlı olabilir ve bu nedenle Windows gerektirebilir.

Tamam! Mesele şu ki, DB Sunucunuzu başka bir Makineye ve Uygulamanızı Web Sunucusuna kurmak daha Güvenli. Daha sonra uygulamanızı bir Web Bağlantısı ile DB'ye bağlarsınız. Teşekkürler.