Создание приложений хоста, эластичных к отказам BGP

Это не будет работать, если будут иметь или будут заботиться о снимках от VM.

Можно использовать vmware-vdiskmanager для расширения размера изображения. Необходимо будет завершить работу виртуальной машины сначала.

После того как Вам изменили размер изображения, можно использовать инструмент раздела диска ОС выбора расширить раздел на диске к новому размеру. Если диск, которого Вы хотите изменить размер, будет системным разделом в Windows, который он кажется, что это, то необходимо будет, вероятно, смонтировать диск в другой виртуальной машине для изменения размеров фактического раздела или начальной загрузки прочь спасательного диска.

Хотя ссылка на vdiskmanager с сервера VMware 1, я полагаю, что то же приложение идет с VMware Workstation.

5
задан 29 July 2009 в 13:57
6 ответов

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

При использовании нескольких серверов DNS в отдельном ASes Вы можете иметь некоторую работу вокруг путем установки низкого TTL и обработки отказа к отдельному веб-серверу в другом центре netblock/data путем изменения DNS, после того как проблемы отмечены. Даже это займет несколько минут однако, самое меньшее.

Править: как указано Chris при выполнении BGP Вам нужны все Ваши коллеги для сбоя, прежде чем Вы станете недостижимыми.

4
ответ дан 3 December 2019 в 01:17
  • 1
    That' s, почему у Вас есть 2 поставщика и Вы взаимодействуете с обоими. –  chris 29 July 2009 в 06:26
  • 2
    Если у Вас есть различные центры обработки данных, Вы могли также баланс загрузки на уровне DNS. В случае маршрутизации дыр, влияющих на один из Вашего DC, пользователи будут все еще иметь неравнодушный возможность соединения даже во время обработки отказа. –  Federico 30 July 2009 в 13:28

Вы вряд ли сможете выполнить BGP, если Вы не будете иметь, по крайней мере,/23 адресного пространства Поставщика Independant и имеете число ASN. По сути, необходимо доверять хостинговой компании. Изменения маршрутизатора имеют тенденцию быть довольно редкими, таким образом, вероятность этой проблемы, происходящей снова, является тонкой. Вы могли исследовать любой SLA, который Вы имеете с ними, но это, вероятно, просто собирается включить получение возврата Ваших сборов за хостинг.

Что касается контроля, у нас есть выделенный сервер вне нашей сети, которую мы используем в качестве внешнего сервера Nagios. Вы могли купить дешевый сервер VPS и использование что контролировать вещи от PoV внешнего пользователя. Например, мы проверяем SMTP и работу HTTP, вместо того, чтобы проверить, что exim и апач работают, который мы делаем на нашем внутреннем контроле.

3
ответ дан 3 December 2019 в 01:17
  • 1
    Можно, вероятно, рекламировать/24 так же легко как/23 - поставщики могут суммировать это, но вероятный you' ll получить IP-адреса от них во всяком случае, таким образом, это isn' t кризис... –  chris 29 July 2009 в 06:18
  • 2
    Если you' ре, использующее пространство PA, it' s очень вряд ли это you' d должны или хотят выполнить BGP. Довольно много мест также отфильтрует сети, меньшие, чем маршруты/23 для сокращения их таблиц маршрутизации. –  David Pashley 29 July 2009 в 10:27
  • 3
    Люди с маршрутизаторами меньшего размера могут отфильтровать к/23, но поставщикам won' t и they' ре те Вы заботитесь о. Если you' ре, двойное размещенный и соединенный, чтобы доказать и provB и иметь адресное пространство в provB' s присвоения, you' ll все еще быть покрытыми, потому что доказывают и одноранговый узел provB в восходящем направлении Вас и даже если почти все остальные суммируют маршруты вниз к/20 (ради аргумента) Вы можете быть прокляты уверенные, которые доказывают и provB don' t суммирует далеко customer' s маршрут. Удаленный сеанс скачкообразно двинется на provB' s сеть прямо до повреждения затем, потому что они взаимодействуют с, доказывают, используют это для остальной части прохождения. –  chris 29 July 2009 в 15:02
  • 4
    Кроме того, контроль из внешней сети будет иметь другие преимущества перед контролем BGP: это обнаружит отказы не-BGP. –  bortzmeyer 30 July 2009 в 11:00

Для записи это существует несколько бесплатных систем контроля BGP и систем аварийной сигнализации. Ни один не обеспечивает разрешение 15 млн, как Вы хотите. И, так как у Вас может быть много других причин отключения электричества, контролирование возможности соединения IP с внешней стороны является единственным действительным решением.

Общая статья о контроле BGP, на французском языке.

2
ответ дан 3 December 2019 в 01:17

В зависимости от того, как вещами является установка, размер netblock того, чтобы быть рекламируемым, и как вещи становятся агрегированными в восходящем направлении, Вы можете использовать один из сценариев зеркала для контроля объявлений BGP для блока, в котором находится сервер.

Может быть легче просто проверить с помощью ping-запросов и Ваш хост и маршрутизатор один шаг назад с Вашего сервера с внешней стороны. Можно использовать traceroute для определения который адрес использовать.

Существует очень мало, можно сделать, чтобы препятствовать тому, чтобы хостинговая компания делала это снова. Чтобы сделать так, у Вас должны были бы быть маршрутизатор или другой хост рабочий BGP, подключенный к Вашему поставщику как минимум. Если у Вас также нет другого поставщика, это справка привычки, если они случайно выключают пиринговый маршрутизатор.

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

0
ответ дан 3 December 2019 в 01:17
  • 1
    Он говорил приблизительно 15 млн из времени простоя. Чтение зеркал займет больше времени, чем это. Проверка с помощью ping-запросов с внешней стороны является действительно лучшим решением. –  bortzmeyer 30 July 2009 в 10:59

Ваши опции довольно ограничены. Можно вопить и кричать на поставщика, можно переместиться к другому поставщику, можно получить 2 различных диапазона IP и рекламировать сервисы на обоих и иметь короткий TTLs на записях DNS.

Но

Если Вы действительно хотите решить это, переместитесь в средство Колорадо с meetme комнатой и купите пропускную способность и IP-адреса от пары поставщиков. Затем зарегистрируйте ASN в arin (или независимо от того, что регистратор корректен для того, везде, где Вы живете), и одноранговый узел с поставщиками сами.

При покупке достаточного количества пропускной способности не будет трудно заставить их выкашливать/24 или/23. Пиринг также будет довольно легким, в зависимости от размера средства Колорадо и суммы пропускной способности, о которой Вы собираетесь быть просьбой.

Если Вы выписываете большие чеки, и Вы действуете как Вы, знают точно, что Вы хотите (и что Вы хотите, разумно), не трудно сделать этот материал. Если Вы сдадите его в аренду своему "поставщику", то Вы всегда будете на немом конце палки.

0
ответ дан 3 December 2019 в 01:17
  • 1
    Опасайтесь поставщиков, которые будут " кашель up"/24 или/23 адресного пространства на основе того, сколько Вы тратите, а не доказуемая потребность. Возможности, они нарушают правила, на которые они согласились при становлении LIR. Условие адресного пространства Поставщика Independant вне Вашего сервиса provider' s руки. AFAIK никакой RIRs сделает присвоение PI на основе размера счета... –  Russell Heilling 29 July 2009 в 12:37
  • 2
    У поставщиков есть много адресов. Они владеют ими, Вы используете их, Вы изменяете поставщиков, Вы отдаете адреса. Никакая потребность говорить с регистратором за исключением числа AS. Потребность, которую Вы предоставляете поставщику, состоит в том, что Вы хотите, чтобы это было надежно. Единственная реальная опасность состоит в том, что немного более трудно измениться далеко от поставщика, который дает взаймы Вам их адресное пространство, но that' s всегда случай, если Вы не получаете свои адреса непосредственно из реестра, который, как Вы говорите, немного более тверд (Вы делаете потребность продемонстрировать потребность, как описано в одном из документов, которые я связал с). –  chris 29 July 2009 в 14:29
  • 3
    Как Russell говорит - I' d быть очень осторожным, если LIR готов обойти процесс приложения/документации только для получения продажи. Это могло поместить присвоения и LIR в опасности. Необходимо продемонстрировать потребность LIR, и LIR должен сделать это доступным для RIR. Изменение нумерации всегда возможно, но это, конечно, isn' t легкий. –  Dan Carley 29 July 2009 в 14:54
  • 4
    ISPs выделяют netblocks все время. Как это несколько отличающееся, за исключением того, что you' ре, связывающее AS с этим netblock и рекламирующее его к поставщикам? Там isn' t любое забавное продолжение бизнеса - у Вас есть законная потребность в двойной дом Ваше предприятие и Вы don' t нужно гигантское выделение адресов, таким образом, Вы просто получаете адреса от поставщика, которого я принимаю, отчасти, каков их бизнес. Возможности - Вы, может даже просто получить/29 от них, и Ваши два поставщика рады направить их. Они не могут появиться в глобальных таблицах маршрутизации, но that' s не проблема. –  chris 29 July 2009 в 15:20
  • 5
    Если/29 является частью ProviderA' s выделение и не обнаруживается через ProviderB от ядра, и ProviderA затем внезапно больше не объявляют об этом, как делает сеть о которой (не объявляют), через ProviderB, на самом деле помогают? –  Vatine 29 July 2009 в 15:24
  1. Можно контролировать объявления поставщика путем выяснения у общедоступных серверов маршрутизации (http://www.traceroute.org/#Route%20Servers) о префиксе, который Вы используете. Можно автоматизировать этот вид контроля telneting эти серверы маршрутизации.
  2. Если Вы используете достаточно пропускной способности, имеете бюджет и навыки для такого развертывания, можно попросить число AS и диапазон IP-адреса. Однако это является дорогостоящим, и так как RIRs выходят из адресов IPv4, необходимо будет дать реальное доказательство потребностей.
0
ответ дан 3 December 2019 в 01:17

Теги

Похожие вопросы