Обнаружение дублирующегося IP-адреса от неправильно клонированных виртуальных машин

Один из наших рабочих серверов был "клонирован" для создания вторичной тестовой среды. Исходный сервер является виртуальной машиной (среда VMware vSphere) соединенный с доменом и со статическим IP-адресом.

Когда клонированный VM был включен, виртуальный сетевой адаптер был включен. Имя компьютера не было изменено. Ни один не был IP-адресом. Так или иначе те два сервера с тем же именем DNS и IP-адресом сосуществовали на том же домене в течение нескольких дней - возможно, целый неделя. Мы будем заняты, возмещая убытки некоторое время...

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

Править
Я не ищу инструкции или совет относительно того, как клонировать VM. Я не один, учитывая, что задача. Я хочу знать, как к быстро (или сразу) обнаруживают, когда два computers/workstations/VM имеет то же имя DNS.

ОБНОВЛЕНИЕ
Я решил осуществить "проверку" при запуске основного сервиса SQL Server, который попытается определить, был ли хост SQL клонирован. (Обратите внимание, что эта тактика только относится к VM's, которые являются хостами SQL Server.)

TLDR: твердый код название хост-машины SQL и домен в сохраненном proc и сравнивает те значения с SERVERPROPERTY(N'MachineName') и DEFAULT_DOMAIN(). Сделайте что-то решительное, если значения не соответствуют.

Если кому-либо интересно, я вел блог об этом: SQL Server: Нападение Клонов

Последние мысли
Я, вероятно, должен был упомянуть это, когда я первоначально отправил вопрос: Я - SQL Server DBA. Даже при том, что я не тип системного администратора, я действительно работаю с ними. Я не нахожусь в той же "команде" как системные администраторы, но я не отгорожен от них также. Я ценю весь вход и многочисленные ответы на мой вопрос. Большинство указало, что проблемой является учебная проблема, и я должен обучить включенных. Я не могу не согласиться. Это - разумный, превентивный подход. Но... почти все за пределами области SQL Server находится вне моего контроля. Системные администраторы приходят и уходят. Они действуют и принимают решения, независимые от моих требований и потребностей. Однако я действительно управляю тем, что происходит с точки зрения SQL Server. Я могу все еще быть превентивным, даже после того, как дело сделано. Так как мое решение собственной разработки определено для SQL Server, теперь очевидно, что я должен был отправить свой вопрос на https://dba.stackexchange.com/, я думаю, что существует все еще некоторое значение к наличию вопроса здесь, но если модератор хочет переместить его, я понимаю.

2
задан 13 April 2017 в 15:43
4 ответа

Когда вы клонируете виртуальную машину в среде vSphere, у вас есть возможность «настроить гостевую» при клонировании или развертывании виртуальных машин из шаблона ...

Здесь вы можете указать имя, изменить настройки сети, указать членство в домене и сгенерировать новый SID (для операционных систем Microsoft) . Это все, что вам нужно сделать в будущем.

5
ответ дан 3 December 2019 в 08:36

Скорее всего, в средстве просмотра событий были журналы, указывающие на конфликты IP-адресов. Любая система мониторинга, которая собирает и фильтрует журналы событий, должна иметь возможность обнаруживать это и запускать предупреждения.

На физических управляемых коммутаторах вы, вероятно, могли бы обнаружить и предупредить о дублировании MAC-адреса - я недостаточно знаком с виртуальными коммутаторами vmware, чтобы знать, что варианты, которые у вас могут быть там.

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

Надеюсь, одна машина «выиграла» все время, и изменения не распространились на оба сервера!

4
ответ дан 3 December 2019 в 08:36

Ничто не заменит хорошую политику управления IP. Конец. Плавник. FIN-ACK.

Независимо от контекста, нет никакого способа предотвратить глупость людей с IP-адресами, если только программное обеспечение не сделает все возможное, чтобы запретить это, - а обычно это невозможно.Откуда он знает, что вам не требуется несколько виртуальных машин для хранения этих адресов, и вы будете подключать к сети только одну из них за раз? Это не задача программного обеспечения - контролировать это. Задача администратора - ценить свою работу настолько, чтобы не создавать сбоев из-за конфликта IP-адресов.

Это один из тех уроков, которые администраторы должны усвоить, будь то тяжелый путь или неизбежная паника в 3 часа ночи, которая случается, когда другие люди обучение на собственном горьком опыте.

  • Вы не ошибаетесь с рисками конфликтов IP.
  • Внимательность, которую вы проявляете при работе с чем-то, имеющим IP-адрес чего-то важного, должно быть больше или равняться вашему желанию продолжать получать зарплату.
  • Что еще более важно, вы не можете предполагать, что что-то предотвратит или обнаружит их для вас - кроме вашего собственного усердия и преклонения колен перед помазанным источником IP-правды вашей организации.

tl; dr, no кто-нибудь умнее IPAM. Назначение IP-адреса или клонирование устройства - это религиозная функция, которая должна сопровождаться благословением IPAM. Вера в языческие обычаи, предназначенные для предотвращения или смягчения конфликтов интеллектуальной собственности, приведет только к предопределенной гибели. Игнорируйте его божественное руководство на свой страх и риск.

(Я понимаю то, что вы пытаетесь сделать. Я действительно делаю, и я уважаю его. Но нет другого истинного решения, кроме страха со стороны тех, кто хочет сохранить свою работу.)

2
ответ дан 3 December 2019 в 08:36

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

Между тем, это может помочь вам идентифицировать гостевые виртуальные машины с дублирующимися IP-адресами, уже присутствующими в вашей среде. Вам понадобится PowerCli, и имейте в виду, что члены кластера изначально используют один и тот же IP-адрес.

$vcserver = "your-vcenter-server-name"
Add-PSsnapin VMware.VimAutomation.Core
Connect-VIServer $vcserver
$results = Get-VM | Select -ExpandProperty Guest | % {
   $name = $_.HostName
   $_.IPAddress | % {
      New-Object PSObject -Property @{
         HostName = $name
         IP = $_
      }
   }
}
Disconnect-VIServer

Затем найдите дубликаты с это :

$count = @{}
$results | % { $count["$($_.IP)"] += 1 }
$count.Keys | ? { $count["$_"] -gt 1 } | % {
   $dup = $_
   $results | ? { $_.IP -eq $dup }
} | ft
1
ответ дан 3 December 2019 в 08:36

Теги

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