Чому не бажано мати базу даних та веб-сервер на одній машині?

Слухаючи інтерв'ю Скотта Хензельмана з командою Stack Overflow ( частина 1 та 2 ), він був впевнений, що SQL-сервер та сервер додатків повинні бути на окремих машинах. Це просто для того, щоб переконатися, що якщо один сервер порушений, обидві системи недоступні? Чи переважає проблема безпеки складність двох серверів (додаткові витрати, виділене мережеве з'єднання між ними, більше обслуговування та ін.), Особливо для невеликого додатка, де жодна частина не використовує занадто багато процесора чи пам'яті? Навіть з двома серверами, при одному з яких сервер порушений, зловмисник все-таки може завдати серйозної шкоди, видаляючи базу даних або псуючи код програми.

Чому це може бути така велика справа, якщо продуктивність не є проблемою?

1. Безпека. Ваш веб-сервер живе в DMZ, доступний для загального доступу до Інтернету та приймає недовірені дані від анонімних користувачів. Якщо ваш веб-сервер піддається злому, і ви дотримуєтесь найменших правил привілеїв під час підключення до вашої БД, максимальна експозиція - це те, що ваша програма може зробити через API бази даних. Якщо у вас бізнес-рівень між ними, у вас є ще один крок між вашим зловмисником та вашими даними. Якщо, з іншого боку, ваша база даних знаходиться на тому ж сервері, зловмисник тепер має кореневий доступ до ваших даних та сервера.
2. Масштабованість. Збереження вашого веб-сервера без стану дає змогу масштабувати веб-сервери горизонтально майже без особливих зусиль. Це дуже важко горизонтально масштабувати сервер бази даних.
3. Продуктивність. 2 коробки = 2 рази CPU, 2 рази ОЗУ і 2 рази шпинделі для доступу до диска.

Враховуючи це, я, безумовно, бачу розумні випадки, що жоден із цих моментів насправді не має значення.

Це насправді важливо , (ви можете абсолютно спокійно запустити свій сайт з веб / бази даних на тій же машині), це просто найпростіший крок масштабування ..

Це саме те, що зробив StackOverflow - починаючи з роботи однієї машини під керуванням IIS / SQL Server, потім, коли він почав сильно завантажуватися, був придбаний другий сервер і на нього переміщений SQL-сервер.

Якщо продуктивність не є проблемою, не витрачайте гроші на придбання / обслуговування двох серверів.

З іншого боку, посилаючись на іншого блогу Скотта (Watermasyck, з Telligent) - вони виявили, що більшість користувачів можуть пришвидшити веб-сайти (використовуючи сервер спільноти Telligent), розмістивши базу даних на тій же машині, що й веб-сайт. Однак, у випадку з клієнтами, зазвичай, сервер db & web є єдиними додатками на цій машині, і веб-сайт не сильно напружує машину. Потім ефективність відсутності необхідності надсилати дані по мережі більше, що компенсувало посилене напруження.

Я думаю, що великим фактором буде продуктивність. І веб-сервер / код програми, і SQL Server кешуватимуть зазвичай запитувані дані в пам'яті, і ви вбиваєте свою кеш-ефективність, запускаючи їх в одному просторі пам'яті.

Том в цьому правильний. Деякі інші причини полягають у тому, що це не рентабельно та є додаткові ризики для безпеки.

Веб-сервери мають інші вимоги до апаратного забезпечення, ніж сервери баз даних. Сервери бази даних працюють краще з великою кількістю пам'яті та дуже швидким масивом дисків, тоді як веб-серверам потрібно лише достатньо пам'яті для кешування файлів та частих запитів БД (залежно від налаштувань). Що стосується ефективності витрат, то два сервери не обов'язково будуть дешевшими, однак співвідношення продуктивності та вартості повинно бути вищим, оскільки вам не доведеться використовувати різні програми, що конкурують за ресурси. З цієї причини вам, ймовірно, доведеться витратити набагато більше на один сервер, який обслуговує обидва і пропонує еквівалентну продуктивність двом спеціалізованим.

Турбота про безпеку полягає в тому, що при порушенні роботи однієї машини вразливий і веб-сервер, і база даних. З двома серверами у вас є приміщення для дихання, оскільки 2-й сервер все ще буде захищений (принаймні на деякий час).

Також є деякі переваги масштабування, оскільки вам, можливо, доведеться підтримувати лише кілька серверів баз даних, які використовуються безліччю різних веб-додатків. Таким чином, у вас менше роботи над застосуванням оновлень або виправлень та налаштуванням продуктивності. Я вважаю, що існують інструменти управління сервером для полегшення цих завдань (хоча в одному випадку).

Безпека - це головне питання. В ідеалі ваш сервер баз даних повинен сидіти за брандмауером з відкритими тільки портами, необхідними для доступу до даних. Ваша веб-програма повинна підключатися до сервера баз даних з обліковим записом SQL, який має достатньо прав для роботи програми та не більше. Наприклад, ви повинні видалити права, які дозволяють скидати об’єкти, і, звичайно, ви не повинні з'єднуватися за допомогою облікових записів, таких як "sa".

У випадку, якщо ви втратите веб-сервер на викрадення (тобто повну ескалацію привілеїв до прав адміністратора), найгіршим випадком є ​​те, що база даних вашої програми може бути порушена, але не весь сервер бази даних (як у випадку, якщо сервер бази даних та веб-сервер були однаковою машиною). Якщо ви зашифрували рядки підключення до бази даних, і хакер недостатньо кмітливий, щоб розшифрувати їх, то все, що ви втратили, - це веб-сервер.

Одним із факторів, про який ще не було сказано, є балансування навантаження. Якщо ви почнете думати про веб-сервер і базу даних як про окремі машини, ви оптимізуєте для меншої кількості мережних поїздок, а також стає легше додати другий веб-сервер або другий двигун бази даних у міру збільшення потреб.

Я можу сказати з власного досвіду, що часто корисно розміщувати веб-сервер і базу даних на різних машинах. Якщо у вас є додаток, який потребує ресурсів, це може легко спричинити максимальний цикл процесора на апараті, що фактично зупинить машину. Однак якщо ваша програма обмежено використовує базу даних, напевно, не буде нічого спільного з ними сервером.

Нічого собі, ніхто не доводить до того, що якщо ви фактично купуєте SQL-сервер за 5-кілограмовий долар, ви, можливо, захочете використовувати його більше, ніж веб-додаток. Якщо ви використовуєте експрес, можливо, вам все одно. Я бачу, що сервери SQL запускають Бази даних для 20-30 додатків, тому розміщувати його на веб-сервері було б не розумно.

По-друге, залежить від того, для кого саме сервер. Я працюю для фінансових компаній та уряду. Таким чином, ми використовуємо шалений біль у дуповому підході, щоб використовувати лише відростки та обмеження портів від веб-сервера до SQL. Тож якщо веб-додаток зламається. Єдине, що може зробити хакер, - це спроби виклику, оскільки обліковий запис користувача на веб-сервері заблоковано, щоб бачити / викликувати проростки в БД. Тож тепер хакер повинен розібратися, як потрапити в БД. Якщо його на веб-сервері добре, до його виду легко дістатися.

Я погоджуюся з Даніелем Ервікером - питання безпеки в основному є хибним.

Якщо у вас є налаштування єдиного вікна з веб-сервером і тільки база даних для цього веб-сервера на ньому, якщо цей веб-сервер порушений, ви втрачаєте і веб-сервер, і лише базу даних для цього конкретного додатка.

Це точно те саме, що відбувається, якщо ви втратите веб-сервер під час налаштування на 2 сервери. Ви втрачаєте веб-сервер і просто базу даних для конкретної програми.

Аргумент про те, що "решта цілісності сервера БД зберігається" там, де ви встановили 2-сервер, не має значення, оскільки в першому сценарії кожен інший сервер баз даних, що стосується будь-якої іншої програми (якщо такі є), також не змінюється. - будучи, як вони, розміщені в інших місцях.

Аналогічно до питання, яке ставить Кев ', що з усіма іншими базами даних, що знаходяться на сервері БД? Все, що ви втратили, - це одна база даних ".

• якщо ви розмістили програму та базу даних на одному сервері, ви б розмістили на цьому сервері лише бази даних, що стосуються цієї програми. Таким чином, ви не втратили жодних додаткових баз даних в одному серверному налаштуванні порівняно з декількома налаштуваннями сервера.

Навпаки, в 2-х серверних установках, коли зловмисник мав доступ до веб-сервера, а також через проксі, обмежені права (у кращому випадку) на сервер баз даних, вони могли піддавати небезпеці бази даних будь-якої іншої програми повільні запити, що займають пам'ять, або максимізація наявного місця на сервері бази даних. Виділяючи додатки на власні проблеми, дуже схожі на віртуалізацію, ви також ізолюєте їх з метою безпеки позитивно.

Це залежить від застосування та мети. Коли висока доступність та продуктивність не є критичною, непогано не розділяти БД та веб-сервер. Особливо враховуючи підвищення продуктивності - якщо пристрій робить велику кількість запитів до баз даних, значну кількість завантаження мережі можна видалити, зберігаючи все в одній і тій же системі, зберігаючи час відповідей низьким.

Я думаю, що це тому, що обидві машини зазвичай потребують оптимізації різними способами. Крім того, я не маю уявлення, ми запускаємо всі наші програми на базі сервера-бази даних на одній машині - дано, що ми не публічні, - але у нас не було проблем.

Я не можу уявити, що занадто багато людей піклується про те, щоб одна машина була порушена через обидва, оскільки веб-додаток, як правило, має майже необмежений доступ до даних, як мінімум, до схеми всередині бази даних.

Цікавить, що можуть сказати інші.

Я слухав цей подкаст, і це було кумедно, але аргумент безпеки для мене не мав сенсу. Якщо ви зламали сервер A, і цей сервер може отримати доступ до даних на сервері B, ви негайно отримаєте доступ до даних на сервері B.

Ліцензії на базу даних не є чіткими і часто стягуються за центральний процесор, тому, відокремлюючи веб-сервери, ви можете знизити вартість ліцензій на вашу базу даних.

Наприклад, якщо у вас 1 сервер, який працює як в Інтернеті, так і в базі даних, що містить 8 процесорів, вам доведеться заплатити за 8 ліцензійних процесорів. Однак якщо у вас є два сервери з кожним 4 процесором і працює база даних на одному сервері, вам доведеться платити лише за 4 ліцензії на процесор

Додаткове занепокоєння викликає те, що бази даних люблять забирати всю наявну пам'ять і зберігати її в резерві, коли вони хочуть її використовувати. Ви можете змусити його обмежувати пам'ять, але це може значно уповільнити доступ до даних.

Аргументація наявності реального збільшення продуктивності роботи сервера баз даних на веб-сервері є хибним аргументом.

Оскільки сервери бази даних беруть рядки запитів і повертають набори результатів, даних, що фактично надходять з сервера даних на веб-сервер, порівняно мало, але кінцева сила, необхідна для обробки запиту та генерування набору результатів, порівняно велика. Оптимізація продуктивності в часі передачі даних, отже, є оптимізацією навколо неправильної речі.

Що стосується безпеки, то переваги мають сервер даних на іншому вікні, ніж веб-сервер. Налаштування такої установки - це не все, що стосується безпеки, але це крок у правильному напрямку.

Що стосується масштабованості, додавати веб-сервери та розміщувати їх у кластер для простого збільшення трафіку досить просто та порівняно дешево. Додавати сервери даних і кластеризувати їх не так просто і дешево. Крім того, веб-сервери та сервери даних мають різні потреби в апаратному забезпеченні, тому декілька вікон допомагають у масштабуванні.

Якщо ви починаєте з малого і маєте лише одну коробку, то хорошим способом було б використання віртуальних машин. Запуск веб-сервера та сервера даних у різних віртуальних машинах на одному хості дає всі прибутки в окремих полях за ціною однієї великої коробки.

Операційна система - це ще одне питання. Хоча для вашої бази даних можуть знадобитися більше простору пам’яті, а тому UNIX, ваш веб-сервер - а точніше ваш сервер додатків, оскільки ви згадуєте лише два яруси - може бути на базі .Net, а тому вимагає Windows.

Гаразд! Ось у чому справа, більш безпечним є встановлення вашого сервера БД на іншій машині, а ваша програма на веб-сервері. Потім ви підключаєте свою програму до БД за допомогою веб-посилання. Дякую.