Доступность Apache с двумя интерфейсами в разных местах. Является ли это возможным?
Я должен в местах (офис и поставщики услуг). Один DNS(bind), обслуживающий наш домен как уполномоченный, и веб-сервер поставщика услуг с нашей корпоративной сетью на частном сервере.
Так..
Сейчас мы планируем обновить наш сервер на интернет-провайдере, и я хотел бы использовать эту ситуацию для улучшения нашего сервиса.
Можно ли смонтировать apache / mysql / php высокой доступности в разных местах?
Я установлю связывающее ведомое устройство на том же новом сервере, поэтому я надеюсь, что это упростит ситуацию, но мне нужны некоторые советы и подсказки о том, как на нем работать.
Благодарю.
3 ответа
Кайл ударил ногтем по голове, ссылаясь на пост, который идентифицирует теорему CAP.
В конечном итоге все сводится к бюджету и ресурсам. Лучший способ справиться с доступностью на границе - использовать сетевые протоколы, такие как BGP. Обеспечение высокой доступности сети проще, поскольку в большинстве случаев вам не нужно беспокоиться о целостности данных.
Использование циклического перебора DNS - это компромиссное решение, менее надежное, но также и жизнеспособное.
Ниже стека у вас есть веб-серверы, которые легче динамически переключать при сбое, как и все, что не связано с хранением данных.
На сервере вы можете копировать MySQL либо через Интернет, либо, желательно, по частной ссылке. Если через интернет, хотя бы используйте SSL. VPN был бы лучше. Это самая сложная часть, над которой я сейчас работаю. Если вы не заботитесь о целостности данных, это просто. Если ваш продукт ориентирован на чтение, у вас есть больше вариантов, так как он менее сложен.
То, к чему я продолжаю возвращаться, является следующим...
Высокая доступность и непрерывность бизнеса - две разные вещи. Среду высокой доступности лучше всего устанавливать в одном и том же средстве в одной и той же внутренней сети, поскольку наилучшие сценарии могут применяться с минимальным риском для данных. Разделение мозга значительно менее вероятно при использовании 3-дюймового последовательного кабеля для мониторинга состояния сервера в дополнение к каналу Ethernet. В случае бедствия часто возникают ручные действия и соглашение об уровне обслуживания, определяющее последствия и сроки. Если главный центр обработки данных сгорел дотла, 30-минутная работа по восстановлению производства не выглядит слишком плохо.
Я мог бы, вероятно, написать книгу на эту тему, так как в ней много чего. Скорее всего, вам придется идти на компромисс с требованиями, основанными на ваших ресурсах, о которых нужно будет сообщить бизнесу. Это не простой запрос.
Одно более простое решение может иметь двух внешних DNS-провайдеров, где один подчинен вашему серверу на одном сайте, а другой - внешнему серверу DNS на другом сайте. Таким образом, если какой-либо провайдер потерпит неудачу, вы сможете изменить входящий путь, используя DNS.
Один веб-путь на одном сайте, один на другом. Двойной мастер на бэкэнде с ручным переключением вверх. Это было бы просто и не рисковало целостностью данных, но для этого нужно было бы вручную.
Это возможно, но вы, вероятно, столкнетесь с большинством проблем с MySQL. Посмотрите этот вопрос Warner о географически различных установках MySQL.
Что касается DNS для аварийного переключения, вы можете прочитать об этом в этом вопросе.
В зависимости от того, чего именно вы хотите достичь, вы можете взглянуть на следующие (бесплатные и открытые) программы:
- Фунт - http://www.apsis.ch/pound/
- Keepalived - http://www.keepalived.org/
- HAProxy - http://haproxy.1wt.eu/
Независимо от того, какое решение вы выберете для обеспечения высокой доступности, вы обязательно должны убедиться, что у вас всегда есть доступные DNS-серверы, но это отдельная проблема.