По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой статье мы расскажем как решить проблему с блокировкой файлов в ESXi.
Проблема
Появляется ошибка при добавлении диска имеющейся виртуальной машины (VMDK) к виртуальной машине, которая не включается:
Failed to add disk scsi0:1. Failed to power on scsi0:1
Включение виртуальной машины зависает на 95%.
Не удается включить виртуальную машину после развертывания ее из шаблона.
Включение виртуальной машины выдает ошибки доступа к файлам, конфигурации виртуальной машины, или файла подкачки:
Unable to open Swap File
Unable to access a file since it is locked
Unable to access a file [filename] since it is locked
Unable to access Virtual machine configuration
В записях журнала появляются похожие записи:
WARNING: World: VM xxxx: xxx: Failed to open swap file [path]: Lock was not free
WARNING: World: VM xxxx: xxx: Failed to initialize swap file [path]
При открытии консоли для виртуальной машины может возникнуть ошибка:
Error connecting to [path][virtual machine].vmx because the VMX is not started
Виртуальная машина сообщает о конфликтных состояниях питания между центральным сервером управления vCenter Server и пользовательским интерфейсом ESXi хост.
При открытии файла .vmx с помощью текстового редактора (например, cat или vi) появляются похожие записи:
cat: can't open '[name of vm].vmx': Invalid argument
Решение
Цель блокировки файлов
Для предотвращения непредвиденных изменений в ценные системные файлы и файлы виртуальной машины, их необходимо заблокировать. В определенных обстоятельствах блокировка сохраняется, даже с выключенной виртуальной машиной. Таким образом, другие ESXi хосты не смогут получить доступ к заблокированным файлам, даже если виртуальная машина не запускается.
Файлы виртуальной машины, заблокированные во время выполнения, включают в себя:
VMNAME.vswp
DISKNAME-flat.vmdk
DISKNAME-ITERATION-delta.vmdk
VMNAME.vmx
VMNAME.vmxf
vmware.log
Быстрый первичный тест
Поставьте DRS (Планировщик Распределения Ресурсов) в режим обслуживания. С его помощью вы сможете выбрать хост, пока вы включаете виртуальную машину. Если DRS не используется, передайте ВМ другому хосту.
Если это не удается, попробуйте включить питание виртуальной машины на других узлах кластера.
Машина должна включиться, когда она окажется на узле, который заблокировал файлы.
Если ВМ по-прежнему не включается, рассмотрите действия, предложенные ниже.
Действия по устранению неполадок: поиск хоста заблокированного файла
Чтобы определить заблокированный файл, попробуйте включить виртуальную машину. Во время включения питания ошибка может отображаться или записываться в журналы виртуальной машины. Ошибка и запись в журнале идентифицируют виртуальную машину и файлы:
Чтобы найти блокирующий узел, запустите утилиту vmfsfilelockinfo с узла, который не может открыть заблокированный файл.
Чтобы узнать IP-адрес хоста, который заблокировал файлы, необходимо запустить утилиту vmfsfilelockinfo для файла VMDK flat, delta или sesparse для VMFS или для файла .UUID. lck для vSAN. Утилита vmfsfilelockinfo потребует следующий материал:
Заблокированный файл
Имя пользователя и пароль для доступа к VMware vCenter Server (при отслеживании MAC-адреса хостом ESX.)
Например:
Запустите команду:
~ # vmfsfilelockinfo -p /vmfs/volumes/iscsi-lefthand-2/VM1/VM1_1-000001-delta.vmdk -v 192.168.1.10 -u administrator@vsphere.local
Результат будет приблизительно такой:
vmfsflelockinfo Version 1.0
Looking for lock owners on "VM1_1-000001-delta.vmdk"
"VM1_1-000001-delta.vmdk" is locked in Exclusive mode by host having mac address ['xx:xx:xx:xx:xx:xx']
Trying to make use of Fault Domain Manager
----------------------------------------------------------------------
Found 0 ESX hosts using Fault Domain Manager.
----------------------------------------------------------------------
Could not get information from Fault domain manager
Connecting to 192.168.1.10 with user administrator@vsphere.local
Password: xXxXxXxXxXx
----------------------------------------------------------------------
Found 3 ESX hosts from Virtual Center Server.
----------------------------------------------------------------------
Searching on Host 192.168.1.178
Searching on Host 192.168.1.179
Searching on Host 192.168.1.180
MAC Address : xx:xx:xx:xx:xx:xx
Host owning the lock on the vmdk is 192.168.1.180, lockMode : Exclusive
Total time taken : 0.27 seconds.
Примечание: в течение жизненного цикла работающей виртуальной машины ее файлы могут менять тип блокировки. Вид блокировки (mode) обозначает тип блокировки на файле. Список видов блокировки:
mode 0 = отсутствие блокировки
mode 1 = эксклюзивная блокировка (файл vmx работающей виртуальной машины, использует VMDK-диск (flat or delta), *vswp и т.д.)
mode 2 = блокировка «только для чтения» (read-only). (Например, для файла данных flat.vmdk работающей машины со снапшотами)
mode 3 = блокировка для одновременной записи с нескольких хостов (например, используется для кластеров MSCS или FTVMs)
Чтобы узнать название процесса, который заблокировал файл, запустите команду lsof на хосте, заблокировавшем файл, и укажите название нужного файла:
~ # lsof | egrep 'Cartel|VM1_1-000001-delta.vmdk'
Результат будет приблизительно такой:
Cartel | World name | Type | fd | Description
36202 vmx FILE 80 /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/VM1/VM1_1-000001-delta.vmdk
Из результата вы узнаете Cartel ID заблокировавшей машины – например, 36202. Теперь, с помощью следующей команды, выведете на экран список активных Cartel ID:
~ # esxcli vm process list
Информация активных виртуальных машин сгруппирована по названиям машин. Формат приблизительно такой:
Alternate_VM27
World ID: 36205
Process ID: 0
VMX Cartel ID: 36202
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a9 dc 9f bf
Display Name: Alternate_VM27
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM27/Alternate_VM27.vmx
………
Найдя нужный вам VMX Cartel ID, вы узнаете название машины, заблокировавшей ваш файл. Если никакие процессы не отображаются, можете найти виртуальные машины с подключенным vmdk. Замените VMDKS_TO_LOOK_FOR на необходимый vmdk. В результате будет список всех зарегистрированных виртуальных машин, и VMDK отобразится под виртуальной машиной, которая заблокировала файл:
for i in $(vim-cmd vmsvc/getallvms | grep -v Vmid | awk -F "/" '{print $2}' | awk '{print $1}'); do echo $i && find ./ -iname $i | xargs grep vmdk | grep -Ei VMDKS_TO_LOOK_FOR ; done
Снятие блокировки
Машину, которая не включается, переместите на заблокировавший хост и снова попробуйте включить ее.
Чтобы снять блокировку, извлеките VMDK-диск или выключите машину, которая удерживает блокировку.
Перезагрузите хост, который заблокировал файл.
Обратитесь к VMware storage team, vSAN team или разработчику NFS за дальнейшей помощью, так как проблемы с метаданными могут мешать управлению блокировками.
Снятие блокировки .lck file (только для NFS)
Файлы на виртуальной машине могут быть заблокированы через NFS storage. Такие файлы заканчиваются на .lck-#### (где #### - значение поля fileid, которое можно получить из запроса GETATTR для заблокированного файла).
Внимание: для безопасного извлечения файлов машина должна быть выключена.
Примечание: Тома VMFS не имеют .lck файлов. Механизм блокировки для томов VMFS расположен в метаданных тома VMFS.
Проверка целостности файла конфигурации виртуальной машины (.vmx)
Если виртуальная машина не включается, причина может быть в наличие двух дисков в файле .vmx. Извлеките один из дисков и попробуйте включить машину снова.
Команда touch *, которая раньше использовалась для устранения неполадок с заблокированными снапшотами vmdk, теперь записывает время последнего изменения файла, который должен быть остановлен и запущен с помощью vmkfstools-D или chmod-s * или vmfsfilelockinfo * для идентификации блокировки.
В одной из предыдущих статей мы рассматривали такой инструмент сетевого инженера как Puppet. Как мы выяснили, это решение экономит кучу времени администратора в сетях, которые насчитывают большое количество узлов. При этом в силу кроссплатформенности данное решение позволяет осуществлять настройку различных операционных систем и их версий для корректной работы сети. Эта программа имеет клиент-серверную архитектуру, то есть периферийные машины, на которых установлена клиентская часть, запрашивают и получают обновленные файлы с актуальными параметрами конфигурации, а затем программа осуществляет обновление параметров операционной системы в автоматическом режиме. Сегодня мы разберем конкретные примеры использования данного решения -зачем оно нужно и где оно применяется.
На самом деле, сфера применения данного решения довольно широка. Это и небольшая локальная сеть группы разработчиков небольшого приложения на Android, сети покрупнее у компаний вроде небольших торговых сетей, сети больших организаций (таких, например, как сеть промышленного предприятия), и сети мегакорпораций, насчитывающие внутри себя десятки тысяч узлов.
Как мы и писали ранее, манифесты Puppet, которые пишутся на языке, имеющем определенное сходство с Ruby (на котором и написана, в общем-то программа Puppet), хранятся в хранилище на сервере. Актуальные конфигурации настроек выдаются по запросам от клиентских машин. Это позволяет осуществлять быструю передачу однотипных настроек конфигурации, а затем устанавливать их параллельно на каждой клиентской машине, используя ее аппаратные мощности.
Это решение применяется во многих компаниях. Официальными партнерами Puppet являются Нью-йоркская фондовая биржа NYSE, которая является частью межконтинентальной фондовой биржи ICE. На текущий момент более 75% серверов ICE управляются посредством Puppet. Применение данного решения позволило снизить нагрузку на администратора теперь один администратор без снижения производительности может обслуживать в 2,2 раза больше серверов, чем раньше. Значительно повышается скорость подготовки среды там, где раньше требовалось 1-2 дня, Puppet справляется примерно за полчаса. Кроме этого, Puppet замечательно справляется с передачей настроек безопасности, что позволяет обеспечить общую безопасность во всей системе, исключая уязвимости на периферии.
Также использует Puppet такой представитель IT-индустрии, как компания Splunk.Inc. Эта компания занимается разработкой систем анализа данных для крупных корпораций и имеет офисы в 12 странах мира. С помощью Puppet здесь реализованы улучшения работы облачной технологии, а также улучшилась поддержка конечных пользователей. Специалисты компании отмечают значительное ускорение развертывания сети, и более эффективное управление клиентской средой, за счет лучшей согласованности Puppet по сравнению с ранними программными решениями. Кроме того, Puppet экономит время разработчиков если ранее многие машины требовали ручной корректировки настроек, то сейчас все происходит автоматически, позволяя выделять высвобождаемое время для разработки новых программных решений и обслуживания пользователей.
Еще одним ярким примером эффективного применения Puppet является компания Staples один из ведущих производителей канцтоваров в мире. У этой компании широко разветвлённая сеть офисов, поэтому построение надежной и эффективной сети это одна из приоритетных задач. Используя решения Puppet, корпорация Staples развертывает сети более эффективно, а за счет отличной совместимости Puppet с различными операционными системами и другими программными продуктами, Staples успешно комбинирует решения различных команд разработчиков, подбирая и внедряя наиболее эффективные из них в свою систему управления сетью. Также специалисты компании Staples отмечают высокую надежность и эффективность данного решения.
Если же упоминать использование Puppet в сравнительно небольших организациях, то администраторы небольших компаний также отмечают гибкость и удобство этой системы. Если компания насчитывает до 500 сотрудников, то она будет иметь не слишком крупную сеть. Но даже в этом случае сетевой инженер должен произвести настройку каждой машины. Разумеется, настраивать вручную несколько сотен рабочих станций - дело неблагодарное. Поэтому Puppet серьезно сокращает время на обслуживание сети и позволяет админу заняться другими задачами.
Сетевые устройства добавляются в сети для решения целого ряда проблем, включая подключение различных типов носителей и масштабирование сети путем переноса пакетов только туда, куда они должны идти. Однако маршрутизаторы и коммутаторы сами по себе являются сложными устройствами. Сетевые инженеры могут построить целую карьеру, специализируясь на решении лишь небольшого набора проблем, возникающих при передаче пакетов через сетевое устройство.
Рисунок 1 используется для обсуждения обзора проблемного пространства.
На рисунке 1 есть четыре отдельных шага:
Пакет необходимо скопировать с физического носителя в память устройства; это иногда называют синхронизацией пакета по сети.
Пакет должен быть обработан, что обычно означает определение правильного исходящего интерфейса и изменение пакета любым необходимым способом. Например, в маршрутизаторе заголовок нижнего уровня удаляется и заменяется новым; в фильтре пакетов с отслеживанием состояния пакет может быть отброшен на основании внутреннего состояния и т.п.
Пакет необходимо скопировать из входящего интерфейса в исходящий. Это часто связано с перемещениями по внутренней сети или шине. Некоторые системы пропускают этот шаг, используя один пул памяти как для входящего, так и для исходящего интерфейсов; они называются системами с общей памятью.
Пакет необходимо скопировать обратно на исходящий физический носитель; это иногда называют синхронизацией пакета по проводу.
Примечание. Небольшие системы, особенно те, которые ориентированы на быструю и последовательную коммутацию пакетов, часто используют общую память для передачи пакетов с одного интерфейса на другой. Время, необходимое для копирования пакета в память, часто превышает скорость, с которой работают интерфейсы; системы с общей памятью избегают этого при копировании пакетов в память.
Таким образом, проблемное пространство, обсуждаемоениже, состоит из следующего:
Как пакеты, которые необходимо пересылать сетевым устройством, переносятся с входящего на исходящий физический носитель, и как пакеты подвергаются обработке на этом пути? Далее обсуждается часть решения этой проблемы.
Физический носитель – Память
Первым шагом в обработке пакета через сетевое устройство является копирование пакета с провода в память. Для иллюстрации этого процесса используется рисунок 2. На рисунке 2 представлены два этапа:
Шаг 1. Набор микросхем физического носителя (PHY chip) будет копировать каждый временной (или логический) слот с физического носителя, который представляет один бит данных, в ячейку памяти. Эта ячейка памяти фактически отображается в приемное кольцо, которое представляет собой набор ячеек памяти (буфер пакетов), выделенный с единственной целью - прием пакетов, синхронизируемых по сети. Приемное кольцо и вся память буфера пакетов обычно состоят из памяти одного типа, доступной (совместно используемой) всеми коммутирующими компонентами на принимающей стороне линейной карты или устройства.
Примечание. Кольцевой буфер используется на основе одного указателя, который увеличивается каждый раз, когда новый пакет вставляется в буфер. Например, в кольце, показанном на рисунке 2, указатель будет начинаться в слоте 1 и увеличиваться через слоты по мере того, как пакеты копируются в кольцевой буфер. Если указатель достигает слота 7 и поступает новый пакет, пакет будет скопирован в слот 1 независимо от того, было ли обработано содержимое слота 1 или нет.
При коммутации пакетов наиболее трудоемкой и трудной задачей является копирование пакетов из одного места в другое; этого можно избежать, насколько это возможно, за счет использования указателей. Вместо перемещения пакета в памяти указатель на ячейку памяти передается от процесса к процессу в пределах пути переключения.
Шаг 2. Как только пакет синхронизируется в памяти, некоторый локальный процессор прерывается. Во время этого прерывания локальный процессор удалит указатель на буфер пакетов, содержащий пакет, из кольца приема и поместит указатель на пустой буфер пакетов в кольцо приема. Указатель помещается в отдельный список, называемый входной очередью.
Обработка пакета
Как только пакет окажется во входной очереди, его можно будет обработать. Обработку можно рассматривать как цепочку событий, а не как одно событие. Рисунок 3 иллюстрирует это. Перед коммутацией пакета должна произойти некоторая обработка, например преобразование сетевых адресов, поскольку она изменяет некоторую информацию о пакете, используемом в фактическом процессе коммутации. Другая обработка может происходить после переключения.
Коммутация пакета - довольно простая операция:
Процесс коммутации ищет адрес назначения Media Access Control (MAC) или физического устройства в таблице пересылки (в коммутаторах это иногда называется таблицей обучения моста или просто таблицей моста).
Исходящий интерфейс определяется на основе информации в этой таблице.
Пакет перемещается из входной очереди в выходную очередь.
Пакет никоим образом не изменяется в процессе коммутации; он копируется из очереди ввода в очередь вывода.
Маршрутизация
Маршрутизация - более сложный процесс, чем коммутация. Рисунок 4 демонстрирует это.
На рисунке 4 пакет начинается во входной очереди. Тогда коммутационный процессор:
Удаляет (или игнорирует) заголовок нижнего уровня (например, кадрирование Ethernet в пакете). Эта информация используется для определения того, должен ли маршрутизатор получать пакет, но не используется во время фактического процесса коммутации.
Ищет адрес назначения (и, возможно, другую информацию) в таблице пересылки. Таблица пересылки связывает место назначения пакета со next hop пакета. Next hop может быть следующий маршрутизатор на пути к месту назначения или сам пункт назначения.
Затем коммутирующий процессор проверяет таблицу interlayer discovery, чтобы определить правильный физический адрес, по которому следует отправить пакет, чтобы доставить пакет на один шаг ближе к месту назначения.
Новый заголовок нижнего уровня создается с использованием этого нового адреса назначения нижнего уровня и копируется в пакет. Обычно адрес назначения нижнего уровня кэшируется локально вместе со всем заголовком нижнего уровня. Весь заголовок перезаписывается в процессе, называемом перезапись заголовка MAC.
Теперь весь пакет перемещается из очереди ввода в очередь вывода.
Почему именно маршрутизация?
Поскольку маршрутизация-это более сложный процесс, чем коммутация, то почему именно маршрутизация? Для иллюстрации будет использован рисунок 5. Существует по меньшей мере три конкретных причины для маршрутизации, а не коммутации в сети. На рисунке 5 в качестве примера приведена небольшая сеть:
Если канал связи [B,C] является физическим носителем другого типа, чем два канала связи, соединяющиеся с хостами, с различными кодировками, заголовками, адресацией и т. д., то маршрутизация позволит A и D общаться, не беспокоясь об этих различиях в типах каналов связи. Это можно было бы преодолеть в чисто коммутируемой сети с помощью преобразования заголовков, но преобразование заголовков на самом деле не уменьшает количество работы, чем маршрутизация в пути коммутации, поэтому нет особого смысла не маршрутизировать для решения этой проблемы. Другое решение может заключаться в том, чтобы каждый тип физического носителя согласовывал единую адресацию и пакетный формат, но, учитывая постоянное развитие физических носителей и множество различных типов физических носителей, это кажется маловероятным решением.
Если бы вся сеть была коммутируемой, то B должен был бы знать полную информацию о достижимости для D и E, в частности, D и E должны были бы знать адреса физического или нижнего уровня для каждого устройства, подключенного к сегменту хоста за пределами C. Это может быть не большой проблемой в малой сети, но в больших сетях с сотнями тысяч узлов или глобальным интернетом это не будет масштабироваться—просто слишком много состояний для управления. Можно агрегировать информацию о достижимости с помощью адресации нижнего уровня, но это сложнее, чем использовать адрес более высокого уровня, назначенный на основе топологической точки присоединения устройства, а не адрес, назначенный на заводе, который однозначно идентифицирует набор микросхем интерфейса.
Если D отправляет широковещательную рассылку «всем устройствам в сегменте», A получит широковещательную рассылку, если B и C являются коммутаторами, но не если B и C являются маршрутизаторами. Широковещательные пакеты нельзя исключить, поскольку они являются неотъемлемой частью практически каждого транспортного протокола, но в чисто коммутируемых сетях широковещательные передачи представляют собой очень трудно решаемую проблему масштабирования. Трансляции блокируются (или, скорее, потребляются) на маршрутизаторе.
Примечание. В мире коммерческих сетей термины маршрутизация и коммутация часто используются как синонимы. Причина этого в первую очередь в истории маркетинга. Первоначально маршрутизация всегда означала «переключаемая программно», тогда как коммутация всегда означала «переключаемая аппаратно». Когда стали доступны механизмы коммутации пакетов, способные переписывать заголовок MAC на аппаратном уровне, они стали называться «коммутаторами уровня 3», которые в конечном итоге были сокращены до простой коммутации. Например, большинство «коммутаторов» центров обработки данных на самом деле являются маршрутизаторами, поскольку они действительно выполняют перезапись MAC-заголовка для пересылаемых пакетов. Если кто-то называет часть оборудования коммутатором, то лучше всего уточнить, является ли это коммутатором уровня 3 (правильнее - маршрутизатор) или коммутатором уровня 2 (правильнее - коммутатором).
Примечание. Термины канал связи и соединение здесь используются как синонимы. Канал связи - это физическое или виртуальное проводное или беспроводное соединение между двумя устройствами.
Equal Cost Multipath
В некоторых проектах сети сетевые администраторы вводят параллельные каналы между двумя узлами сети. Если предположить, что эти параллельные каналы равны по пропускной способности, задержке и т. д., они считаются равными по стоимости. В нашем случае каналы считаются многопутевыми с равной стоимостью (equal cost multipath - ECMP).
В сетевых технологиях в производственных сетях часто встречаются два варианта. Они ведут себя одинаково, но отличаются тем, как каналы группируются и управляются сетевой операционной системой.