По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой статье мы расскажем как решить проблему с блокировкой файлов в 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 * для идентификации блокировки.
Современные предприятия во многом доверяют технологии контейнеризации, чтобы упростить развертывания сложных приложений и управление ими.
Контейнеры собирают необходимые зависимости внутри одного пакета. Таким образом, вам не нужно беспокоится о том, что возникнут какие-либо конфликты зависимостей в эксплуатационной среде.
Контейнеры можно переносить и масштабировать, но для последнего маневра вам понадобится инструмент управления контейнерами.
На сегодняшний день Docker Swarm и Kubernetes – самые популярные платформы для оркестрации контейнеров. Они оба имеют свое конкретное назначение и определенные преимущества и недостатки.
В данной статье мы рассмотрим оба из них, чтобы помочь в выборе инструмента управления контейнерами с учетом ваших требований.
Что такое Docker Swarm?
Docker Swarm – это платформа оркестрации контейнеров с открытым исходным кодом, встроенная в Docker. Он поддерживает оркестрацию кластеров механизмов Docker.
Docker Swarm преобразует несколько экземпляров Docker в один виртуальный хост. Кластер Docker Swarm обычно состоит из трех элементов:
Node - нода
Service и Task – службы и задачи
Load balancer - балансировщик нагрузки
Ноды – это экземпляры механизма Docker, контролирующие ваш кластер, а также контейнеры, используемые для запуска ваших служб и задач.
Балансировка нагрузки также является частью кластеров Docker Swarm и используется для маршрутизации запросов между нодами.
Преимущества Docker Swarm
Docker Swarm довольно прост в установке, поэтому он хорошо подходит для тех, кто только начинает осваивать мир оркестрации контейнеров.
Он легковесный.
В контейнерах Docker Swarm обеспечивает автоматическую балансировку нагрузки.
Поскольку Docker Swarm встроен в Docker, то он работает с интерфейсом командной строки Docker. Помимо этого, он без проблем работает с существующими инструментами Docker, такими как Docker Compose.
Docker Swarm обеспечивает рациональный выбор нод, что позволяет выбрать оптимальные ноды в кластере для развертывания контейнера.
Имеет собственный Swarm API.
Недостатки Docker Swarm
Не смотря на множество преимуществ, Docker Swarm имеет также несколько недостатков.
Docker Swarm сильно привязан к Docker API, что ограничивает его функциональность в сравнении с Kubernetes.
Возможности настройки и расширения в Docker Swarm ограничены.
Что такое Kubernetes?
Kubernetes – это портативный облачный инфраструктурный инструмент с открытым кодом, изначально разработанный Google для управления своими кластерами. Поскольку он является инструментом оркестрации контейнеров, то он автоматизирует масштабирование, развертывание и управление контейнерными приложениями.
Kubernetes имеет более сложную структуру кластера, чем Docker Swarm.
Kubernetes – это многофункциональная платформа, главным образом потому, что она с выгодой для себя использует активную деятельность мирового сообщества.
Преимущества Kubernetes
Он способен поддерживать большую рабочую нагрузку и управлять ей.
У него большое сообщество разработчиков открытого ПО, поддерживаемого Google.
Поскольку он имеет открытый исходный код, то он предлагает широкую поддержку сообщества и возможность работы с разнообразными сложными сценариями развертывания.
Его предлагают все основные поставщики облачных услуг: Google Cloud Platform, Microsoft Azure, IBM Cloud и AWS.
Он автоматизирован и поддерживает автоматическое масштабирование.
Он многофункционален, имеет встроенный мониторинг и широкий спектр доступных интеграций.
Недостатки Kubernetes
Несмотря на то, что Kubernetes обладает большим набором функций, он также имеет и несколько недостатков:
Процесс обучения Kubernetes достаточно сложный, и для освоения Kubernetes требуются специальные знания.
Процесс установки достаточно сложен, особенно для новичков.
Поскольку сообщество разработчиков открытого ПО работает достаточно продуктивно, Kubernetes требует регулярной установки обновлений для поддержания последней версии технологии без прерывания рабочей нагрузки.
Для простых приложений, которые не требуют постоянного развертывания, Kubernetes слишком сложный.
Kubernetes VS Docker Swarm
Теперь, когда мы узнали все преимущества и недостатки Kubernetes и Docker Swarm, давайте посмотрим, чем же они отличаются друг от друга.
Основное различие этих двух платформ заключается в их сложности. Kubernetes хорошо подходит для сложных приложений, а Docker Swarm разработан для простоты использования, что говорит о том, что его предпочтительнее использовать с простыми приложениями.
Далее приведем подробное описание нескольких различий между Docker Swarm и Kubernetes:
Установка и настройка
Kubernetes можно настроить, но сделать это будет не так просто. Docker Swarm установить и настроить намного легче.
Kubernetes: в зависимости от операционной системы ручная установка может отличаться. Если вы пользуетесь услугами поставщика облачных технологий, то установка не требуется.
Docker Swarm: экземпляры Docker обычно одинаковы для различных операционных систем и поэтому довольно просты в настройке.
Балансировка нагрузки
Docker Swarm предлагает автоматическую балансировку нагрузки, а Kubernetes – нет. Однако в Kubernetes легко интегрировать балансировку нагрузки с помощью сторонних инструментов.
Kubernetes: службы можно обнаружить через одно DNS-имя. Kubernetes обращается к контейнерным приложениям через IP-адрес или HTTP-маршрут.
Docker Swarm: поставляется со встроенными балансировщиками нагрузки.
Мониторинг
Kubernetes: имеет встроенный мониторинг, а также поддержку интеграции со сторонними инструментами мониторинга.
Docker Swarm: нет встроенных механизмов мониторинга. Однако он поддерживает мониторинг через сторонние приложения.
Масштабируемость
Kubernetes: обеспечивает масштабирование в зависимости от трафика. Встроено горизонтальное автомасштабирование. Масштабирование Kubernetes включает в себя создание новых модулей и их планирование для узлов с имеющимися ресурсами.
Docker Swarm: обеспечивает быстрое автоматическое масштабирование экземпляров по запросу. Поскольку Docker Swarm быстрее развертывает контейнеры, то это дает инструменту оркестрации больше времени на реакцию, что позволяет масштабировать по требованию.
Какую платформу все же выбрать?
И Kubernetes, и Docker Swarm служат для конкретного назначения. Какой из них лучше, зависит от ваших текущих потребностей или потребностей вашей организации.
При запуске Docker Swarm – это простое в использовании решение для управления вашими контейнерами. Если вам или вашей компании не нужно управлять сложными рабочими нагрузками, то Docker Swarm – правильный выбор.
Если же ваши приложения имеют более ключевую роль, и вы хотите включить функции мониторинга, безопасности, высокой доступности и гибкости, то Kubernetes – вот ваш выбор.
Подведем итог
Благодаря этой статье мы узнали, что такое Docker Swarm и Kubernetes. Также мы узнали об их плюсах и минусах. Выбор между этими двумя технологиями достаточно субъективен и зависит от желаемых результатов.
В данной статье рассматриваются вопросы, которые следует задать системным администраторам, и меры предосторожности, которые они должны предпринять при устранении неполадок.
Как правило, устранение неполадок не рассматривается на каких-либо официальных занятиях, - это все то, что большинство из нас в конечном итоге усваивает на собственном горьком опыте. Как действовать, где искать, как определить первопричину возникших проблем - все это навыки, которые мы обычно развиваем с течением времени.
Жизненный цикл сеанса устранения неполадок обычно включает:
Обнаружение - обнаружение проблемы
Идентификация - понимание того, в чем проблема
Анализ - определение причины проблемы
Исправление - исправление того, что было не так
Профилактика - принятие мер для предотвращения повторения проблемы
Систематический подход к устранению неполадок может помочь быстрее выявить основную причину проблемы, которая нарушает работу сервера или приложения. Вот несколько шагов и вопросы, которые нужно задать себе:
1. Что только что изменилось?
Наиболее частая первая реакция на что-то, что перестает работать - это спросить: «Хорошо, а что изменилось?» Изучение последних изменений - это тоже действие, которое, скорее всего, окупится, если на самом деле какое-то существенное изменение было сделано только что. Ищите файлы, особенно файлы конфигурации, которые могли быть изменены, приложения или пакеты, которые были только что добавлены, службы, которые только что были запущены, и т. д. Не упускайте из виду тот факт, что многие системные проблемы возникают не сразу. Примеры того, что идет не так, не связано с недавним изменением, включают:
Медленно заканчивается место на диске
Можете столкнуться с ошибкой конфигурации, которая раньше просто не активировалась из-за несоблюдения определенных условий
2. Какие ошибки я наблюдаю?
Обратите особое внимание на любые ошибки, которые отображаются на системной консоли или в файлах журнала. Указывают ли эти ошибки на какую-то конкретную причину? Вы видели раньше подобные ошибки? Видите ли вы какие-либо проявление тех же ошибок в старых файлах журнала или в других системах? Что вам говорят поисковые запросы в Интернете? Независимо от того, с какой проблемой вы столкнулись, вы вряд ли будете первым системным администратором, столкнувшимся с ними.
3. Как себя ведет система или сервис?
Возможно, стоит обратить внимание на симптомы проблемы. Система или служба работают медленно или полностью непригодны для использования? Может быть, только некоторые пользователи не могут войти в систему. Может быть, не работают только некоторые функции. Выделение того, что работает, а что нет, может помочь вам сосредоточиться на том, что не так.
4. Чем эта система отличается от той, которая является рабочей?
Если вам повезло, что у вас есть дублирующие системы, и у вас есть шанс сравнить ту, которая не работает, с другой. Возможно, вы сможете определить ключевые различия, которые могут помочь выявить причину.
5. Каковы вероятные точки останова?
Подумайте, как работает приложение или сервис и как/где могут возникнуть проблемы. Полагается ли он на конфигурационный файл? Нужно ли ему общаться с другими серверами? Задействована ли база данных? Записывается ли он в определенные лог-файлы? Включает ли это несколько процессов? Можете ли вы легко определить, все ли необходимые процессы запущены? Если можете, систематически устраняйте потенциальные причины.
6. Какие инструменты для поиска и устранения неисправностей могут быть полезны?
Подумайте об имеющихся у вас инструментах для поиска системных проблем. Некоторые из них могут оказаться полезными:
top - для оценки производительности, включая проблемы с памятью, файлом подкачки и загрузкой
df - для проверки использования диска
find - для поиска файлов, которые были изменены за последний день
tail -f - для просмотра последних записей журнала и наблюдения за тем, появляются ли все еще ошибки
lsof - чтобы определить, какие файлы были открыты конкретным процессом
ping - быстрая проверка сети
ifconfig - проверка сетевых интерфейсов
traceroute - проверка подключений к удаленным системам
netstat - проверка сетевых подключений
nslookup - проверка разрешений хоста
route - проверка таблиц маршрутизации
arp - проверка IP-адреса на записи MAC-адреса в вашем кеше
7. Происходит что-нибудь неприятное?
Не исключайте возможность того, что кто-то вмешивался в вашу систему, хотя большинство хакеров предпочли бы делать свою работу так, чтобы вы ничего не заметили.
8. Что мне НЕ делать?
Не путайте симптомы и причины. Каждый раз, когда вы определяете проблему, спрашивайте себя, почему она существует. Будьте осторожны, чтобы не уничтожить «доказательства», пока вы лихорадочно работаете над тем, чтобы вернуть свою систему в оперативный режим. Скопируйте файлы журнала в другую систему, если вам нужно освободить дисковое пространство, чтобы вернуть систему в рабочее состояние. Затем вы можете изучить их позже, чтобы выяснить, что вызвало проблемы, над решением которых вы работаете.
Если вам нужно восстановить файл конфигурации, сначала сделайте копию файла (например, cp -p config config.save), чтобы вам было легче узнать, как и когда файл был изменен, и что вам нужно сделать, чтобы все заработало. Имейте ввиду, что для поиска решения возникшей проблемы вы, возможно, примените большое количество решений. И в последствии не сможете запомнить, какое из решений устранило проблему.
9. Что мне делать?
Запишите все свои действия. Если вы используете PuTTY для подключения (или какой-либо другой инструмент, позволяющий записывать взаимодействия с вашей системой), включите ведение журнала. Это поможет вам, когда вам нужно будет проанализировать, что произошло и как вы решили проблему. Если у вас достаточно места на диске, вы также можете использовать скрипт для записи сеанса входа в систему (например, сценарий устранения неполадок `date% m% d% y`). Если у вас нет возможности сохранять логи, записывайте все, что вы делали и что видели. Вы можете не вспомнить все это позже, особенно если вы находитесь в состоянии стресса. Вы можете помнить шаги, но не порядок, в котором вы их выполняли.
После устранения проблемы задокументируйте, что произошло. Возможно данная проблема возникнет снова, и вам, возможно, придется объяснить своему руководству или клиентам, что произошло, и как вы собираетесь предотвратить это в будущем. По возможности подумайте, как можно избежать данной проблемы в будущем. Можете ли вы улучшить свои службы мониторинга так, чтобы проблемы с дисковым пространством, памятью и сетью, изменения конфигурации и т. д. были решены задолго до того, как они повлияют на работающие службы?