Что ж, мой выделенный сервер за 379 долларов снова стал холодным во второй раз за месяц. Мне нужно найти способ подключить другой сервер к другому провайдеру, и я могу просто включить его, если это произойдет снова. Как лучше всего справиться с подобной ситуацией?
Замена неработающего сервера.
Серьезно - добавление второго сервера работает. но это не так просто, особенно когда в дело вмешиваются базы данных. В конце концов, вам нужно копировать вещи в реальном времени.
Если сервер выходит из строя дважды в месяц, возможны две вещи:
Во всех случаях я бы взялся за это с этой стороны. В основном - сервер сломан, замените его по гарантии. Дважды в месяц - это слишком много.
Думаю, для начала было бы найти надежного провайдера с приличным SLA по времени безотказной работы.
Что касается вашего вопроса - как получить некоторую форму избыточности, если у вас есть второй сервер в отдельном месте - в первую очередь требуются некоторые знания о том, что вы делаете на сервере (хостинг веб-сайтов? электронная почта? некоторые другие услуги ?)
Стандартную настройку LAMP можно сделать относительно избыточной, используя rsync для синхронизации файлов с резервным компьютером и DNS (по сути, настраивая соответствующие записи A с низкими значениями TTL), чтобы разрешить переключение между двумя активными сайтами.
Недостатки: это медленный и неуклюжий способ сделать это, требует ручного вмешательства и требует DNS, который не обрабатывается ни одним из двух блоков (не проблема, если вы используете внешнего поставщика DNS).
Самая большая проблема в этом типе решения - это база данных: базовая репликация базы данных довольно проста (ну, относительно), но возможность беспрепятственного переключения обратно после прекращения простоя - нет. Кроме того, запуск системы, зависящей от удаленной фиксации, может значительно замедлить работу. Сценарий также усложняется наличием двух машин у двух провайдеров - традиционный балансировщик нагрузки будет сложно реализовать, поскольку сети физически разделены, а работа, необходимая для чего-то вроде haproxy или общего решения для общего хранилища, находится по другую сторону уменьшающейся кривая доходности.
вы потратите больше времени на то, чтобы понять, как поступить с переключением (а затем на его мониторинг и управление), чем на то, чтобы на самом деле запустить достойный сервис.
Итак, я предполагаю, что ответ такой, как уже упоминалось: создание чего-то, что позволяет вам просто переключаться с одной машины на другую, зависит от того, что вы делаете, но почти гарантированно будет более затратным и сложным, чем просто получение твердого SLA. поддерживаемый хостинг с хорошо организованным провайдером. сначала сделайте это, а затем позаботьтесь о балансировке нагрузки и избыточности.
Я бы посоветовал вам получить резервный выделенный сервер, очевидно, он не должен быть таким мощным, как ваш нынешний сервер, поскольку он будет использоваться только для целей резервного копирования. Я бы посоветовал этим ребятам www.smarterdedicatedserver.com поскольку они действительно дешевы и обеспечивают надежную защиту своего центра обработки данных. В плане настройки аварийного переключения или даже балансировки нагрузки вы можете использовать эту компанию http://www.autofailover.com/ или что-то подобное. Вам также необходимо поддерживать синхронизацию двух серверов, я бы либо написал сценарий, чтобы делать это каждую ночь, и использовал бы что-то вроде зеркального отображения базы данных (SQL Server) для синхронизации баз данных в реальном времени или какую-либо другую стратегию репликации. Это определенно будет дополнительной работой, но время безотказной работы будет намного лучше. Никакая служба не может обеспечить 100% бесперебойную работу, поэтому, если это важно, я бы установил второй выделенный сервер.
Я думаю, твой план верен. Очевидно, что с вашим текущим провайдером что-то не так, и ваша уверенность в его способности предоставлять надежные услуги падает. Я бы побрел на форум выделенных серверов на Обсуждение веб-хостинга и узнайте, что люди говорят о поставщиках в вашем ценовом диапазоне.
Это очень обширная предметная область без дополнительных деталей. В частности, нам нужно знать, были ли сбои связаны с линией связи или с оборудованием.
Если первое, рассмотрите возможность размещения или размещения во вторичном центре обработки данных с репликацией в реальном времени.
В последнем случае нам нужно знать, как быстро вам нужно вернуться в Интернет после сбоя. Это определит, смотрим ли мы на репликацию в реальном времени (в том же или другом центре обработки данных) или на восстановление из резервной копии на диске / ленте.
Если вам нужна конкретная информация о чем-либо, нам нужно знать, какие приложения вы используете, которые должны быть высокодоступными.