Стоит ли использовать отдельный сервер MySQL?


8

Аналогичный вопрос превратился мнение супа над здесь : Так что, может быть , нет никакого «правильного» ответа на этот вопрос , но я хочу , чтобы проверить с сообществом.

Мой клиент собирается запустить телевизионную рекламу. Они ожидают трафика в 7-значном отделе в течение ближайшего месяца. Моя работа состоит в том, чтобы сервер не упал.

Мой вопрос: стоит ли разбивать базу данных MySQL на отдельный сервер, который обслуживает только базу данных. Затем я хочу иметь несколько серверов, которые содержат кодовую базу и обслуживают Apache, взаимодействуя с блоком базы данных. Все будут виртуальными контейнерами.

Я НЕ (думаю), что хочу использовать несколько серверов БД - кажется, это создаст ненужную сложность и потенциальные ошибки / узкие места.

Я ошибаюсь? Хотелось бы получить некоторые мнения по этому поводу. Спасибо.

Ответы:


16

Мы использовали отдельный сервер MySQL в нескольких случаях, когда магазины сталкивались с большим трафиком. Есть несколько преимуществ для этого

  1. Выделенные серверы баз данных могут быть адаптированы к конкретным потребностям MySQL, которые отличаются от веб-сервера
  2. При необходимости легко добавить второй (сбалансированный по нагрузке) сервер базы данных в кластер.
  3. Когда ваша база данных выходит из строя, она не приводит к сбою внешнего интерфейса, поэтому вы можете отобразить приличное предупреждение или страницу с ошибкой.

Когда Magento правильно кэшируется с помощью Varnish или любого другого расширения FPC, основным узким местом будет база данных из того, что я испытал. Реальная сила будет требоваться для вашей базы данных. Таким образом, вы можете начать с относительно небольшого веб-сервера и вкладывать больше средств в сервер базы данных.


13

Безопасность:

В дополнение к ответу Сандера я бы добавил, что на определенных уровнях соответствия PCI это требование :

Отдельные веб-серверы и серверы баз данных CHD хранятся в базе данных в массовом порядке, что делает их ценной целью для злоумышленника. Отдельный сервер базы данных означает, что доступ может строго контролироваться (ограниченная подверженность). Требуется в разделе 1 PCI DSS.

Источник: http://www.focusonpci.com/site/index.php/PCI-101/technical-requirements.html

Разделяя обязанности сети и базы данных, вы ограничиваете свое воздействие. Обычно ваша база данных находится в частном сегменте вашей сети и недоступна публично.

В PCI также предлагается статическое VPN-соединение между вашим web / db, и настоятельно рекомендуется обнаружение вторжений на сетевом оборудовании. В случае компрометации БД будет изолирован и VPN-соединение будет разорвано, так что, даже если ваше приложение и ваш ключ шифрования теперь скомпрометированы, доступ к хранилищу данных заблокирован и недоступен.

Высокая доступность / аварийное восстановление:

Сандер здесь. Иди, проголосуй за него. Я бы добавил, что в случае даже небольшой задачи по обслуживанию, такой как создание резервной копии файловой системы или дамп базы данных, ваша база данных в лучшем случае будет ограничена только для чтения на некоторое время. В крайних случаях я видел тайм-ауты ожидания блокировки и очереди процессов, которые заполняли все доступные соединения в очереди или сбрасывались. Сайт "уходит", эффективно.

Вы можете уменьшить это, выделив свою базу данных и запланировав веб-сервер для перевода сайта в режим обслуживания во время этих окон резервного копирования без каких-либо последствий для файловой системы веб-сервера.


1
Безопасность делает это легким делом, PCI-DSS или нет. Как и в случае любых конфиденциальных данных, между фронтальной системой и базой данных должен быть межсетевой экран.
Ник

0

Я хотел бы добавить свой 1 цент: «Когда разрабатывается производственная среда, рассмотрите возможность размещения приложения и базы данных на разных серверах». Это даст следующие преимущества напрямую или напрямую:

  • В целом лучшая производительность (Ваше приложение имеет больше ресурсов)
  • Более надежная система (сбой или блокировка одного может не повлиять на другое. Конечно, приложение может работать не так, как нужно, но один компонент)
  • Выделенные ресурсы по мере необходимости (Вы можете распределять ЦП / ОЗУ / Хранилище для каждого сервера по мере необходимости)
  • Повышенная безопасность (только за исключением того, что вы разрешаете подключение к базе данных за пределами вашей машины, но это можно уменьшить с помощью ограничений брандмауэра на основе IP-адреса или аналогичных подходов)
  • Обязательное требование для достижения высокой доступности (HA)
  • Системы, которые легко удовлетворить потребности аварийного восстановления (DR)
  • На мой взгляд, только недостатками являются более высокая стоимость и больше серверов для управления.

Спасибо и Реагрд, Имран Джавед Зия

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.