Мы собираемся разместить наши серверы в двух местах, чтобы обеспечить высокий уровень избыточности и избежать критики пропускной способности. Два сервера находятся в разных локальных сетях, но обмениваются данными через сеть WAN (через Интернет). Один из серверов является основным, а другой - второстепенным. Проблема в том, что программное обеспечение состоит не только из базы данных, но также имеет файлы на главном сервере, которые также необходимо передать на второй сервер. Мы используем SQL СЕРВЕР 2005
Основные требования к нашему дизайну следующие:
Решение I Передача данных между серверами SQL: репликация транзакций Передача файлов между серверами: Симпатичный вариант безопасности FTP: VPN В этом решении мы собираемся использовать VPN для защиты связи между двумя серверами. Данные между двумя серверами SQL отправляются через репликацию транзакций.
Решение II Передача данных между серверами SQL: резервное копирование и восстановление Передача файлов между серверами: Симпатичный вариант безопасности FTP: VPN Здесь мы собираемся создавать резервную копию базы данных каждые шесть часов и отправлять данные с файлами через безопасный туннель - VPN - на второй сервер по FTP. Недостатком этого решения является то, что оно использует большую часть полосы пропускания и требует гораздо больше времени, чем первое решение.
Решение III Передача данных между SQL-серверами: веб-синхронизация с репликацией слиянием Передача файлов между серверами: WebDAV через SSL Security Option: - Здесь мы используем репликацию слиянием для нашей репликации, хотя мы не собираемся использовать двунаправленную опцию репликации слиянием . Мы собираемся использовать веб-синхронизацию вместо VPN. Чтобы передать файлы на второй сервер, мы собираемся использовать WebDAV через SSL для защиты соединения. Возможный недостаток этого варианта заключается в том, что я не уверен, что передача данных будет безопасной и может вызвать проблемы с безопасностью на главном сервере. Даже для веб-синхронизации мы должны открыть порт 443, что также может вызвать проблемы с безопасностью, особенно если мы не используем VPN в этом решении.
Решение IV Передача данных между серверами SQL: репликация транзакций Передача файлов между серверами: FTP или WebDAV через SSL. Опция безопасности: настройка прокси-сервера. Прокси-сервер настроен как многосетевой сервер для предотвращения доступа неавторизованных пользователей в Интернете к работающему внутреннему серверу. SQL Server. Прокси-сервер настроен как многосетевой сервер для предотвращения доступа неавторизованных пользователей в Интернете к внутреннему серверу, на котором работает SQL Server. В этом варианте мы должны открыть порты: 1433 и 21. Я не уверен, что это вызывает проблемы с безопасностью, особенно потому, что мы не используем VPN в этом решении.
Примечание. Вы считаете, что мы не используем такие функции, как зеркалирование или доставка журналов. Мы не можем использовать такие функции, как зеркалирование в SQL Server, потому что в этих случаях резервный сервер либо недоступен, либо - при использовании моментального снимка - доступен только для чтения.
Резюме: я предпочитаю использовать решение № 1, потому что он решает все проблемы безопасности и доказал свою безопасность. Благодаря выполнению транзакционной репликации она будет быстрой и может быть расширена на другие источники баз данных, такие как Oracle, в будущем, что имеет значение для пропускной способности. Жду ваших предложений и комментариев по поводу моих решений и с нетерпением жду любых других идей.
Спасибо вам большое за ваш ответ.
Позвольте мне дать вам более ясную картину нашего дела. У нас сейчас есть сервер в сети WAN. Этот сервер содержит как базу данных, так и веб-приложение. Проблема в том, что количество пользователей нашей компании очень велико, но у нас очень низкая линия связи и не хватает пропускной способности. Поэтому, когда они начинают использовать веб-сайт в глобальной сети, его нельзя использовать.
Поэтому мы решили запустить еще один подчиненный сервер в нашем подключении к локальной сети, который будет синхронизироваться с основным сервером. Пользователи компании будут использовать этот сервер как проблему производительности. Я думаю, что это объяснение значительно проясняет вам тему.
Поэтому я хочу использовать репликацию для базы данных (SQL SERVER 2005), а не для аварийного переключения или доступности. Это проблема, о которой я говорил ранее. Обратите внимание, что у нас очень низкая пропускная способность.
И я использую VPN-соединение, потому что безопасность важна для меня, и я не хочу открывать ненужные порты и их недостатки.
Ваш совет использовать DFS для репликации файлов выглядит нормально. Но для DFS есть некоторые ограничения и требования:
Надеюсь, я рассказал вам достаточно подробностей. Я жду твоего ответа.
Если я правильно это читаю и мне нравится думать, что это так, у вас действительно довольно простая проблема. Но только если вы готовы изменить любое из 4 решений.
Я также собираюсь предположить, что ваш бюджет составляет примерно 1-10 миллионов долларов США, учитывая, что вы выразили заинтересованность в переходе на Oracle в будущем, и если у вас нет достаточно большого бюджета, что ж, вы облажались.
Так. Краткое изложение вашего вопроса выше TL; DR. «Мы хотели бы создать кластер баз данных высокой доступности с двумя (или более) серверами на двух (или более) сайтах».
Я не знаю, почему вы все время упоминаете FTP и WebDAV, учитывая, что вы, похоже, очень беспокоитесь о безопасности. FTP совсем не безопасен. WebDAV - это совсем не высокая производительность.
Первый шаг. Получите и сохраните полный контроль над своей сетью. Вам понадобится приличная связь между вашими сайтами. Я думаю, что где-то от 10 до 100 Мбит неуправляемого, нефильтрованного интернета операторского класса. На каждом сайте вам понадобится приличный VPN-маршрутизатор. Что-то вроде Cisco ASA было бы хорошим началом. Затем вы настраиваете защищенную AES IPSec VPN между двумя вашими сайтами.
Для репликации файлов между двумя серверами вы можете использовать DFS. Это встроенный инструмент репликации файловой системы с несколькими главными файлами в Windows Server 2003 и выше. Я не собираюсь подробно объяснять тонкости настройки DFS. Это совсем другой вопрос.
Для репликации базы данных есть количество альтернатив доступны вам, и каждый из них предлагает разные преимущества. Вы не сказали намного больше об архитектуре своего приложения, о том, надеетесь ли вы получить выгоду от улучшенной доступности или улучшенной масштабируемости, или того и другого. Опять же, сам процесс настройки репликации - это вопрос для другого вопроса.
Я предлагаю вам выполнить первоначальную синхронизацию нового сервера базы данных «вручную» с портативным жестким диском USB, что, вероятно, будет намного быстрее, чем синхронизация через Интернет.
Вы также ничего не упомянули об инфраструктуре вашей сети, есть ли у вас отдельные веб-серверы от серверов баз данных? Планируете ли вы их повторить?
TL; DR: используйте передовые отраслевые методы связи между сайтами с помощью безопасной VPN, используйте встроенные системы репликации для баз данных и файловых систем. Забудьте о FTP, WebDAV и прочем дерьме и делайте это как следует. Если вы сделаете это правильно, вероятность укусить вас за задницу меньше.
Что касается части SQL Server, вы захотите использовать репликацию транзакций.
Для репликации файлов вам понадобится DFS. Если это не сработает из-за вашей настройки AD, вы захотите посмотреть на robocopy, используя параметр / sync. DFS не имеет ничего общего с безопасностью, это решение для репликации данных. Для использования DFS требуется, чтобы между двумя сайтами был один лес AD. Это нормально для многосайтовой компании.
Вы, вероятно, захотите посмотреть на обновление с SQL 2005 до чего-то более нового. После этого Microsoft собирается выпустить третью основную версию.
Если у вас возникают проблемы с производительностью из-за того, что пользователи обращаются к веб-сайту, вам, вероятно, потребуется увеличить скорость сети на обоих сайтах, чтобы он мог обрабатывать сетевой трафик всех репликаций данных, с которыми вам придется иметь дело.
Почему нужно, чтобы данные, которые записывают пользователи второго сайта, были доступны только на втором сайте? Если приложение используется (или чаще всего) только со второго сайта, почему бы просто не переместить приложение на второй сайт и попросить всех, кому нужно получить к нему доступ с первого сайта, просто подключиться к серверу на втором сайте?