восстановление после сбоя?
-
Хорошо, вот что вы можете сделать. Вы можете присвоить серверам на вашем сайте DR адрес 192.168.1.0. Для репликации вы можете настроить NAT для серверов DR на 192.168.2.0, чтобы серверы DC могли получить к ним доступ — обратите внимание, что вам необходимо убедиться, что NAT не нарушает репликацию. Затем объявите сеть 192.168.1.0/24 как с сайта DC, так и с сайта DR. Но убедитесь, что вы используете BGP MED, чтобы в обычном режиме весь трафик для 192.168.1.0 направлялся на серверы DC. Если соединение с DC не удалось, удаленные сайты будут маршрутизироваться на сайт DR, используя те же адреса 192.168.1.x. Я не пытаюсь сделать это простым, так как потребуется тестирование, и вам также нужно решить, хотите ли вы автоматическое переключение на резервный сайт в случае сбоя соединения с DC, т. е. что делать, если произошел кратковременный сбой и вы переключились на DR — это может создать больше проблем, чем решить. Поэтому иногда автоматическое переключение на DR не является необходимым. Все действительно зависит от того, сколько времени простоя может выдержать клиент. GSS — более чистое решение, но если все клиенты используют IP-адреса для доступа к серверам, то оно вам мало поможет. Другой вопрос — для чего вы пытаетесь обеспечить DR — т. е. вышеуказанное в отношении BGP работает только в случае сбоя сайта DC, тогда как GSS может обрабатывать сбои отдельных серверов. Как вы, наверное, понимаете, это очень обширная тема.
] Джон
-
Джон Не совсем понимаю, что вы имеете в виду под использованием одних и тех же подсетей на сайте DR. Как вы собираетесь маршрутизировать трафик к одним и тем же подсетям, объявляемым из двух отдельных сайтов? Когда вы говорите, что они хотят иметь возможность их использовать, вы имеете в виду в обычном производстве или просто иметь к ним доступ для применения обновлений и т. д.? Джон
-
Ну, это соответствует моему другому вопросу о туннелировании L2, который я задал несколько недель назад. Я объяснил им, что мы не сможем маршрутизировать исходящий трафик на другую сторону, потому что он будет искать хосты в этой подсети. Теперь, когда это сказано, конечной целью является возможность немедленно переключиться на другой сайт без каких-либо изменений адресов. Я не уверен, что это будет возможно. Мы вообще не используем NAT для нашего трафика; наша сеть полностью основана на IPFR. Мы маршрутизируем с помощью BGP, и мне придется связаться с нашим провайдером, чтобы он направил весь трафик на наш сайт DR, но подсеть на сайте DR отличается от нашей (конечно). Они хотят сделать наш основной сайт и сайт DR более или менее плоской сетью. Мне придется создать больше адресов (в настоящее время мы используем схему класса C), чтобы это работало и у нас было достаточно адресов для перехода через линию. Дополнительная информация о соединении: у нас есть оптоволоконное соединение от нас к провайдеру в их оптоволоконный коммутатор. У них есть соединение от их оптоволоконного коммутатора к нашему DR. По-видимому, они разрешают только 25 MAC-адресов по этому каналу без дополнительной платы. Если бы существовала какая-то настройка NAT для MAC-адресов, я бы надеялся, что смогу настроить наш маршрутизатор «точка-точка» с маршрутизатором на палочке и установить серверы в определенной виртуальной локальной сети, расширить подсеть, а затем передать данные на другой сайт. Хотя адреса для каждого хоста все равно будут меняться. Я не знаю, как люди обращаются с горячим сайтом. Спасибо, Джон!!!! Джон HTH,
Джон *** Пожалуйста, оценивайте все полезные сообщения *** -
Джон Не совсем понимаю, что вы имеете в виду под этим — «Мы вообще не используем NAT для нашего трафика; наша сеть полностью основана на IPFR» что такое IPFR. В любом случае, не забывайте, что вы можете рекламировать одну и ту же подсеть через BGP с разных сайтов с MED, так что если ваш основной ЦОД работает, эти маршруты всегда будут предпочтительнее, чем сайт DR. Но это очень общий комментарий. Многое зависит от того, как работает ваш BGP и от топологии вашей сети. Имейте в виду, что для доступа к этим серверам, когда серверы ЦОД работают, вы всегда можете использовать NAT и рекламировать подсеть с NAT из сайта DR. Я имею в виду доступ с точки зрения администратора на серверах, а не обычный пользовательский трафик. Другой альтернативой является что-то вроде GSS (Global Site Selector). Это фактически позволяет вам иметь один и тот же URL/имя и т. д., указывающий на два разных адреса, т. е. один в вашем ЦОД и один в DR. Если ЦОД выходит из строя, GSS может перенаправить на DR. Вам не нужно использовать один и тот же IP-адрес. Но, очевидно, это зависит от того, использует ли приложение DNS-имена, а не жестко запрограммированные IP-адреса. Джон
-
Джон, IPFR — это IP Frame Relay. Он работает через нашего провайдера, который маршрутизирует трафик для нас. Все наши адреса являются частными, и все подключаются к Интернету через наш корпоративный офис. Лучший способ описать мою топологию — это как «звездочка», но наш провайдер является центром. Если бы мы вышли из строя, все остальные локации не смогли бы никуда выйти. GSS — это что-то от Cisco или это больше связано с сервером? Я не уверен, что маршрутизация с BGP будет работать, потому что я не могу перенести свою подсеть на другой сайт (насколько я знаю). В настоящее время серверы находятся на 192.168.1.0/24, а на сайте DR — на 192.168.2.0/24. Единственное, что я знаю, как сделать, если наш сайт выйдет из строя, — это настроить NAT для этой подсети (192.168.2.0 — выходит как 192.168.1.0) и статический NAT для всего обратно. Вы это имеете в виду? --Джон Надеюсь, это поможет,
Джон *** Пожалуйста, оценивайте все полезные сообщения *** -
Джон Ну, вы могли бы сделать так, т. е. статически настроить NAT для всех адресов 192.168.2.0 как адреса 192.168.1.0. Не совсем понимаю, что вы имеете в виду под «я не могу перенести свою подсеть на другой сайт». Если вы используете BGP, то просто объявите подсеть 192.168.1.0 со своего сайта DR (конечно, с MED, что означает, что DC является предпочтительным). Вам понадобится маршрут в таблице маршрутизации на вашем сайте DR, чтобы сеть BGP была объявлена, но это достаточно просто. GSS — это набор инструментов Cisco. Он в основном действует как авторитетный DNS-сервер имен, но обладает большей интеллектуальностью, чем обычный DNS-сервер. Он хорошо интегрируется с устройствами Cisco для балансировки нагрузки, т. е. модулями CSS и CSM/ACE. Джон
-
Я имел в виду строго ту же подсеть с точки зрения серверов. Я не могу перенести свои IP-адреса на сайт DR, если только вы не знаете, как это сделать.
![] Первоначальный запрос от руководства заключался в том, чтобы у нас был точный дзеркальный образ ОС, IP-адресов и т. д. на сайте DR, но я не уверен, что это возможно, а если и возможно, то я не имею представления, как это настроить.
![] Мне нужно изучить GSS, это звучит многообещающе. --Джон Надеюсь, это поможет,
Джон *** Пожалуйста, оценивайте все полезные сообщения *** -
Джон Вы используете BGP для рекламирования подсетей с ваших сайтов на другие сайты? Джон
-
Да, есть. Но это очень просто. Вот что я вижу: В компании у нас есть 192.168.1.0. Все серверы имеют адреса от 192.168.1.2 до .254. Они реплицируются по оптоволоконной сети на 192.168.2.0 на серверы на сайте DR, которые имеют адреса от 192.168.2.2 до .254. Когда удаленные сайты обращаются к серверам приложений, они настроены как жестко запрограммированные (я думаю) адреса к адресам 192.168.1.0/24. Если корпоративный сайт выйдет из строя, все они должны будут быть исправлены, чтобы перейти на сайт DR 192.168.2.0, или мне придется использовать NAT как 192.168.1.0. Если мне придется использовать NAT как 192.168.1.0, как BGP будет знать, куда отправлять трафик 192.168.1.0 обратно? Должен ли я настроить сеть в процессе bgp на маршрутизаторе 192.168.2.0 для подсети 192.168.1.0? --Джон HTH,
Джон *** Пожалуйста, оцените все полезные сообщения *** -
Спасибо, Джон. Какие ресурсы вы бы мне порекомендовали для этого? Я даже не серверный специалист.
![] --Джон Надеюсь, это поможет,
Джон *** Пожалуйста, оценивайте все полезные сообщения *** -
Джон Я знаю, каково это, кажется, что сетевики всегда занимаются тем, от чего все остальные отказываются. Могу сосчитать, сколько раз это происходило со мной.
![] Это очень хорошее начало — это проект Cisco по обеспечению непрерывности бизнеса, в котором рассматривается множество проблем, с которыми вы сталкиваетесь. http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/dcstslt.html Я помогу, чем смогу.
![] Джон -
Спасибо, Джон! HTH,
Джон *** Пожалуйста, оценивайте все полезные сообщения *** -
Джон Есть ли какая-то причина, по которой мы должны поддерживать одинаковую подсеть как в DC, так и в DR?
-
удалено
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти