Использование моментальных снимков (Snapshots) в Hyper-V

    Моментальные снимки: сложно о простом
    Наверняка многие знакомы с достаточно полезной функцией многих продуктов виртуализации – моментальными снимками, в простонародье – «снапшоты» (snapshots). Снапшот виртуальной машины – это как сохранение в игре: в случае, если где-то сильно накосячил (патч Бармина применил, например) – можно вернуться назад и повторить все заново. В этой статье я попытаюсь более-менее подробно рассказать о работе моментальных снимках и о некоторых нюансах их применения. В статье речь пойдет о Microsoft Hyper-V, но с некоторыми натяжками материал статьи применим и для других систем виртуализации (в частности — VMWare).

    Прежде, чем продолжать – вспомним, из каких компонентов состоит виртуальная машина:
    Файл конфигурации – основа виртуальной машины, хранит все настройки, касающиеся виртуалки. Представляет собой XML-файл, имеющий, как ни странно, расширение XML. В VirtualPC/Virtual Server этот файл имел расширение VMC.
    Файл виртуального диска. Обычно в качестве жесткого диска виртуальные машины используют специальные файлы-образы, имеющие расширение VHD. Этот формат, изначально разработанный фирмой Connectix, после приобретения ее корпорацией Microsoft стал использоваться в продуктах виртуализации, и не только в них: в частности, они используются в Microsoft Software iSCSI Target, а в ОС Windows 7 и Windows Server 2008 R2 с VHD-дисками можно работать на уровне ОС, вплоть до загрузки с них самой операционки.
    Дифференциальные диски – основа технологии снапшотов. При создании снапшота запись в VHD-файл прекращается, и все последующие изменения записываются в отдельный файл, имеющий расширение VHD.
    Сохранение состояния (Save State) – одна из полезных функций системы виртуализации. При сохранении состояния все содержимое памяти виртуальной машины, регистров процессора и т.д. сохраняется в специальные файлы, и виртуалка переходит в состояние «Выключено». После этого можно делать все что угодно, вплоть до перезагрузки хостовой машины, а потом снова запустить виртуалку – и она будет работать, как ни в чем не бывало, ровно в том же состоянии, в каком она была до сохранения. Примерно так же работает функция Hibernate в Microsoft Windows с единственным лишь отличием – сохранение состояния происходит на уровне самой виртуальной машины, а не на уровне гостевой ОС. В VirtualPC и Virtual Server для сохранения содержимого памяти использовался файл с расширением VSV, в Hyper-V же их стало аж целых два – BIN и VSV.
    Файл экспорта. Если виртуальную машину Hyper-V нужно склонировать, или же перенести на другой хост – необходимо произвести операцию экспорта, а затем импорта. При экспорте конфигурационный XML-файл преобразуется в файл с расширением EXP. В VirtualPC и Virtual Server для этого достаточно просто скопировать файлы виртуальной машины, а в Hyper-V придумали импорт/экспорт – как они сами говорят, в целях безопасности.
    Различают два типа моментальных снимков: онлайновый и оффлайновый. Онлайновым называют снапшот, сделанный на виртуальной машине с запущенной гостевой ОС. Соответственно, если виртуальная машина была в состоянии «выключено» — то снапшот будет называться оффлайновым. Для пользователя нет абсолютно никаких различий между онлайновыми и оффлайновыми снапшотами. Различаются они только по составу файлов, потому что при создании снапшота на запущенной виртуалке происходит операция Save State, и данные Save State включаются в состав снапшота

    Онлайн-снапшот:
    • Копия файла конфигурации
    • Дифференциальный диск AVHD
    • Файлы Save State – BIN+VSV
    Оффлайн-снапшот:
    • Копия файла конфигурации
    • Дифференциальный диск AVHD


    Что можно и что нельзя делать с моментальными снимками?



    Как уже было сказано, снапшоты виртуальных машин – это то же самое, что и сохранение в игре. И единственное их назначение – обеспечение точки возврата на случай возможных ошибок. Снапшоты – это не бэкап, и использовать их для аварийного восстановления не получится. Использовать моментальные снимки в production-среде не рекомендуется, потому что это может привести к падению производительности, почему это так – будет понятно далее из статьи. Если необходимо часто создавать резервные копии для защиты от ошибок пользователей – необходимо использовать другие средства, к примеру – инкрементные бэкапы или журналы транзакций, если речь идет о базах данных.
    Помимо этого, необходимо помнить, что управлять снапшотами можно и нужно только через стандартные средства Hyper-V (оснастка MMC Hyper-V Manager, WMI-провайдеры, командлеты PowerShell) и сторонний софт, использующий такие средства – например Microsoft SystemCenter Virtual Machine Manager.

    Итак, что же происходит при создании снапшота?
    image
    Для простоты представим виртуальную машину с одним жестким диском (см. рисунок). Только что мы установили на нее операционную систему, и, прежде чем двигаться дальше – хотим сделать снапшот. При выборе Create Snapshot текущая конфигурация виртуальной машины сохраняется в отдельный файл (Копия конфигурации 1), и создается файл AVHD (Дифференциальный диск AVHD 1). При этом в саму конфигурацию виртуальной машины вносятся изменения, и с этого момента из файла VHD производится только чтение, а вся запись производится только в AVHD-файл (зеленая стрелка). Диск виртуальной машины состоит уже из двух файлов: VHD и AVHD. У нас получился первый моментальный снимок, который для удобства можно назвать «OS Installed» (по умолчанию снапшотам дается имя из имени виртуальной машины с добавлением даты и времени создания).
    Теперь, допустим, что мы что-то сделали (к примеру, установили приложение) и делаем еще один снапшот. Точно так же, как и до этого – конфигурация сохраняется в отдельный файл, создается новый AVHD, и запись перенаправляется уже в него (желтая стрелка). Виртуальный диск состоит уже из трех файлов: VHD и двух AVHD. Для простоты получившийся снапшот можно назвать «Apps Installed».
    Допустим, мы создали один или несколько моментальных снимков. Что же теперь с ними можно сделать? Выбор тут, в принципе, не слишком богат: снапшот можно либо применить (Apply), либо удалить (Delete). По факту, это означает:
    • Apply – возвратиться к точке создания снапшота, при этом все изменения, произошедшие с момента создания снапшота и до настоящего времени будут потеряны.
    • Delete – точка возврата удалится, а все внесенные изменения сохранятся на веки вечные.

    Это нужно четко для себя уяснить, чтобы потом не «наломать дров». Как говорил один специалист – «Delete means Apply, Apply means Delete», и даже еще лучше будет сказать в стиле Маяковского: «Мы говорим «Удалить» — подразумеваем «Применить», мы говорим «Применить» — подразумеваем «Удалить».
    Посмотрим, как это происходит.
    Хотим мы откатиться назад, к моменту окончания установки приложений. Для этого выбираем снапшот «Apps Installed» («Моментальный снимок 2»)и делаем «Apply». Как только мы это делаем – текущая конфигурация виртуалки заменяется копией из состава снапшота (т.е. «Конфигурация» перепишется из «Копии конфигурации 2»). После этого AVHD со внесенными до «отката» изменениями («Дифференциальный диск AVHD 2») удаляется, и создается новый AVHD, в который сразу же перенаправляется запись.
    Теперь, допустим, мы закончили наши эксперименты, и перед вводом виртуальной машины в продакшн хотим удалить все наши снапшоты. Если мы удалим снапшот «Apps Installed» то произойдет следующее:
    • Во-первых, удаляется копия файла конфигурации, и сам снапшот исчезает из списка.
    • Если в данный момент виртуальная машина запущена – AVHD, связанный с этим снапшотом остается, и запись в него продолжается.
    • Как только виртуальная машина останавливается (шатдаун или перезагрузка) – все данные из AVHD записываются в предыдущий AVHD, или в VHD, если мы удаляем первый снапшот, а сам AVHD удаляется. Эта операция называется «Объединение» (Merging). Операция объединения может занять определенное время (в зависимости от объемов данных), в течение которого запустить виртуалку нельзя.
    Теперь рассмотрим более сложную ситуацию. Допустим, мы установили на нашу виртуалку приложение (скажем, MS SQL Server 2005), «поигрались» с ним, а теперь хотим поиграться с другой версией этого приложения (к примеру, MS SQL Server 2008). Если перед установкой ПО мы сделали снапшот (а мы его сделали, «OS Installed»), то мы просто откатываемся на этот снапшот и ставим уже новое приложение. В результате, у нас образуется новая ветвь снапшотов:
    image
    При откате к снапшоту «OS Installed» действующий на тот момент AVHD (в составе снапшота «Apps Installed») удаляется, создается новая копия конфигурации и новый AVHD(«Дифференциальный диск AVHD 3»), относящийся, в нашем случае, к самому VHD. Далее, если мы, к примеру, создадим еще один снапшот (для простоты обзовем его «New Snapshot») – то новый AVHD создастся уже на основе «Дифференциального диска AVHD 3»). Таких ветвей может быть и больше – например, от снапшота «OS Installed» может идти и три, и больше ветвей. Операции Delete/Apply при ветвлении происходят так же, как и было описано, но с некоторыми нюансами. К примеру, если мы теперь захотим удалить снапшот «OS Installed» — то он исчезнет из списка, и удалится копия конфигурации, но объединения после останова виртуальной машины не произойдет. Почему? А все очень просто: поскольку от нашего VHD образуются не один, а аж целых два AVHD – перезаписать сам VHD нельзя: если при перезаписи используется AVHD1 – то AVHD3, и соответственно – все, что на него опираются (в нашем случае это AVHD4) при возможном откате на них работать не будут.
    Вот еще одно «исключение из правил»: допустим, мы удаляем снапшот «Apps Installed». Как мы видим, своего AVHD у него нет. Поэтому удален будет предыдущий по времени AVHD1.
    Если же мы захотим вернуться к снапшоту «Apps Installed» — то создастся новый AVHD на основе AVHD1 (ну то есть новый AVHD2, грубо говоря), а удалится активный на данный момент AVHD4.

    Ну и теперь скажу несколько слов в заключение.


    Во-первых – как я уже говорил, нужно помнить про «Delete means Apply, Apply means Delete», и думать перед нажатием кнопки, дабы не потерять ничего.
    Во-вторых, если виртуальная машина содержит онлайновые снапшоты – ее крайне не рекомендуется экспортировать и переносить на другой сервер. Дело в том, что онлайновый снапшот содержит состояние регистров процессора и содержимое памяти, и применение такого снапшота в другом аппаратном окружении может привести к краху гостевой ОС.
    В-третьих, как уже было сказано – снапшоты не рекомендуется использовать в производственной среде. Наверняка вам известно, что для продакшна рекомендуется использовать виртуальные диски фиксированного размера – для того, чтобы избавиться от фрагментации VHD-файла. Создавая же снапшоты, мы искусственно делим наш виртуальный диск на отдельные файлы – VHD и множество AVHD. На высоконагруженных системах это может привести к некоторому падению производительности. Кроме этого, при удалении снапшотов происходит операция объединения, которая тоже может сказаться на общей производительности системы, а к тому же может повысить время простоя при перезагрузках виртуальной машины. К примеру, если вы удалили один или несколько снапшотов на виртуальной машине, а потом потребовалось ее перезагрузить (к примеру – при установке апдейтов), то загрузка ОС не начнется, пока не завершится полностью операция объединения. Поэтому снапшоты можно использовать перед вводом в продакшн, для экономии времени при установке ПО и начальной настройке. После этого все снапшоты нужно удалить, дождаться окончания объединения, и только затем вводить в продакшн.
    Еще один небольшой момент: в настройках Hyper-V можно задавать отдельно путь для размещения файлов виртуальных машин и путь для размещения VHD. По умолчанию и то и другое хранится на диске C:. Если для хранения VHD планируется использовать, к примеру, высокоскоростной RAID-массив – необходимо хранить на нем не только VHD, но и файлы виртуальных машин. Дело в том, что при создании снапшотов файлы AVHD будут храниться именно в том месте, которое было выбрано для хранения виртуальных машин. И может получиться так, что сам VHD будет храниться на отдельном дисковом массиве, а куча AVHD будет на диске С:, что не есть хорошо.

    На этом я закончу этот пост, и без того уже большой. Прошу прощения за некоторый сумбур, тема при кажущейся простоте немного нетривиальна для объяснения. Для лучшего понимания советую посмотреть скринкаст, с анимированной презентацией и демонстрацией: www.techdays.ru/videos/1490.html

    Если хаброобщественность не будет возражать – я могу дать ссылки на другие свои скринкасты и статьи про Hyper-V, дабы не кросспостить и не копипастить. Надеюсь, кого-то моя статья заинтересовала, в любом случае – спасибо заранее.
    Метки:
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 52
    • +2
      спасибо, полезно.
      • 0
        Обширный материал по функции, спасибо.
        К сведению: Снэпшоты нельзя использовать на виртуализованном Exchange
        • 0
          Нельзя — в смысле, нельзя технически, или рекомендуется? Технических запретов я вроде не видел, да и не слышал. Ну а насчет рекомендуется — это как раз я и говорил про «не использовать в продакшне».
          • 0
            Конечно, слепок снимется, жестких ограничений нет, ведь снэпшоты, это не сервис уровня приложений (application aware). Чтобы сократить операции I/O, Exchange производит чтение и запись не напрямую в базу, а работает с кэшем в оперативной памяти. От сюда прослеживаются две проблемы: либо потеря данных, либо inconsistent database, а может быть всё сразу.
            • +1
              В онлайновых снапшотах (то есть снятых на запущенной виртуалке) происходит дамп оперативки в файл — то же, что и при Save State. Так что кэш не потеряется. Хотя, разумеется, я с Вами соглашусь — снапшотить контроллеры доменов AD, Exchange и SQL-сервера — крайне не рекомендуется, именно поэтому в продакшн-среде снапшоты — unsupported solution.
              • 0
                Насчет онлайновых да, согласен. Еще проблема в скорости работы с разностным диском, возможно это и есть первопричина «неподдерживаемости» решения в продакшене.
                • 0
                  Это да, особенно — если мы имеем цепочку из десятка-другого снапшотов, и, соответственно — разностных дисков — при высоких нагрузках на дисковую подсистему она просто просядет. С другой стороны, MS не рекомендует такие сервисы (это СУБД, Exchange Server, а конкретно — роль Mailbox Server) — виртуализировать вообще.
                  • 0
                    «С другой стороны, MS не рекомендует такие сервисы (это СУБД, Exchange Server, а конкретно — роль Mailbox Server) — виртуализировать вообще.»

                    А можно источник такой рекомендации?
                    • 0
                      Говорили люди на семинарах, так что пруфлинка не будет. Такие рекомендации вполне обоснованы — потому что дисковая система хуже всех поддается виртуализации, в отличие от процессоров и памяти, поэтому высоконагруженные сервисы лучше всего держать на выделенных серверах, особенно — когда критична именно дисковая подсистема.
                      • 0
                        Пруфлинка не будет, но все равно «рекомендации обоснованы» :)
                        Давайте все же в таком случае говорить не о «рекомендациях Microsoft», а о частном мнении некоторых ведущих семинары сотрудников.
                        • 0
                          Никто не мешает для 'высоконагруженных' сред использовать RDM диски.
                          • 0
                            Ох, простите, немного занесло, забыл, что в Hyper-V это называется Pass-through диски.
                          • 0
                            Официально:
                            technet.microsoft.com/en-us/library/aa996719.aspx

                            Microsoft supports Exchange 2010 in production on hardware virtualization software only when all the following conditions are true:
                            (skipped)
                            The Exchange guest virtual machine:
                            * Is running Microsoft Exchange 2010.
                            * Is deployed on the Windows Server 2008 with SP2 or Windows Server 2008 R2 operating system.
                            * Doesn't have the Unified Messaging server role installed. All Exchange 2010 server roles, except for the Unified Messaging server role, are supported in a virtualization environment.
                            This is due to the real-time response requirements associated with voice communications with the Unified Messaging server role.

            • +1
              Чёрт, я сначала прочитал «ментальных снимков». Подумал, что я весь прогресс проспал.
              • 0
                А еще можно делать снапшоты средствами самого NTFS
                При этом производительность никак не страдает.
                А вообще лучшим решением будет размещение например, по iSCSI на отдельной СХД данных
                и выполнение снапшотов средствами самой СХД. можно применять и на продакшене и для бэкапов.
                • 0
                  Не совсем верно, в случае создания снимков файловой системы у запущенной ОС в снимке должны корректно сохраняться открытые файлы, т.е. средствами СХД сделать корректный снимок ФС нельзя. Будет снимок хранилища, но он не будет учитывать состояния открытых файлов, а это все равно, что в момент интенсивной работы дисков нажат RESET, эффект примерно тот же, эффект незакрытых файлов.
                  Снимок средствами файловой системы более корректен, при этом файловые буфера сбрасываются, хотя файл и не закрывается, но шансов потерять данные меньше.
                  • 0
                    При использовании SCOM и при установленых агентах в гостевых системах все происходит корректно. Даже MSSQL c Exchange корректно снапшотятся.
                    • 0
                      Вы имели в виду SCDPM? SCOM ведь, если мне не изменяет память — осуществляет мониторинг, а SCDPM — бэкапит.
                      • 0
                        SCVMM + DPM если быть точнее.
                        • 0
                          Причем виртуальки можно бэкапить только бэта версией DPM2010. Рабочая, но бэта, а вот средствами СХД бэкапить нельзя, DMP не СХД.
                          • 0
                            Если я правильно понял докладчика на семинаре — Symantec BackupExec 2010 тоже поддерживает бэкап виртуалок Hyper-V R2 на лету.
                            • 0
                              Поддерживает, с купленной за 1200уе лицензией и установленным на Hyper-V агентом. =)
                              • 0
                                Ну, DPM вроде тоже не бесплатен :)
                                К тому же цены — это немного выходит за рамки топика, ведь статья — сугубо техническая, а не маркетинговая.
                              • 0
                                Опять же создание резерной копии такого рода инструментом это не создание снапшота файловой системы на СХД.
                              • 0
                                Если использовать VSS Provider от вендора хранилки, то можно получать консистентные snapshot'ы файлов и данных приложений.
                      • 0
                        Не надо путать божий дар с яичницей. Бэкапы, то есть то, что Вы предлагаете и снапшоты виртуальных машин — это немного разные вещи. Те снапшоты, о которых говорится в статье — это всего лишь save game на случай ошибки, чтобы не повторять сначала установку софта, и, возможно, ОС. В частности, это будет удобно для системных программистов, которые из-за бага в своей программе могут так угробить ОС на тестовой виртуалке, что придется переустанавливать ее с нуля, либо же — откатиться на снапшот. Кстати, снапшоты средствами ФС тоже могут повлиять на производительность — по той же причине, что и дифференциальные диски, ибо снапшоты средствами ОС — это те же дифференциальные диски, только не на уровне файлов, а на уровне самой ФС.
                        Кроме этого, снапшот виртуальной машины позволяет так же сохранить и содержимое памяти, то есть позволит откатиться ровно к тому состоянию, которое было до снапшота.
                        • 0
                          Ну, например, VMware уже пришел к тому, что использует shapshot'ы как часть технологии резервного копирования виртуальных машин (VMware Data Recovery). Возможно, MS тоже рано или поздно к этому придет, например в DPM, если изменит схему удаления snapshot'ов.
                          • 0
                            У VMware, кстати, та же проблема с удалением снапшотов. То есть при удалении снапшоты последовательно сливаются увеличиваясь в размерах порой в десятки раз, а потом, слившись, вливаются в actual state. Если при этом еще не забился полостью диск datastore :-]
                            Так что тоже не славбогу.
                            Юзайте снапшоты стораджа.
                            • 0
                              По-видимому, уже пришли — ведь каким-то образом этот самый DPM умеет бэкапить виртуалки «на лету».

                              Снапшоты стораджа — гуд, но это не то же самое, что и снапшоты виртуалки, увы и ах.
                              • 0
                                Увы и ах, он использует для этого VSS.
                                • 0
                                  То есть есть фактически бэкапится только файловая система и все? Фигово :(
                        • 0
                          «В-третьих, как уже было сказано – снапшоты не рекомендуется использовать в производственной среде.»

                          Хотел бы уточнить формулировку: «не рекомендуется использовать в производственной среде» именно снапшоты MS Hyper-V (и VMware ESX).
                          Дело в том, что существует множество разных реализаций снапшотов, в частности, «аппаратная» реализация силами системы хранения. Многие из этих реализаций не имеют описанных проблем и могут успешно применяться и в продакшне.
                          Пример — реализация снапшотов в системах хранения NetApp FAS, где они являются одной из основ решения вообще.

                          Так что не все снапшоты «одинаково полезны».
                          • 0
                            Тема статьи — «Использование моментальных снимков (Snapshots) в Hyper-V».
                            • 0
                              Тем не менее когда вы используете широкораспространенное в индустрии, и появившееся задолго до Hyper-V понятие, в применении к узкочастному случаю конкретной его реализации, то имеет смысл все же уточнять, что речь идет о проблемах конкретной реализации, а не о понятии вобще, чтобы не путать в головах менее подготовленных чем вы читателей.
                              • 0
                                Вот именно поэтому я и написал в заголовке — «в Hyper-V». И по идее этого должно быть достаточно, чтобы даже самый неподготовленный читатель понял, что речь идет именно о Hyper-V, а не о СХД и бэкапах. Что, по-вашему, я еще должен был сделать?
                                • 0
                                  Я бы это написал в форме
                                  «В-третьих, как уже было сказано – снапшоты Hyper-V не рекомендуется использовать в производственной среде.»

                                  Добавлено «Hyper-V».

                                  Нет, я нисколько не настаиваю, если вы принципиально против, это же ваша статья, но так, по-моему, будет яснее.
                                  • 0
                                    Я совсем не против, более того — я даже приветствую конструктивную критику — ведь комментарии сделали тут именно для этого ;)
                                    Просто я думал, что то, что в статье идет речь о Hyper-V — самоочевидно.
                                    • 0
                                      убрать
                                      но с некоторыми натяжками материал статьи применим и для других систем виртуализации (в частности — VMWare).
                                      или добавить акцент на HV
                                      • 0
                                        В VMWare Server / ESX снапшоты работают абсолютно по-другому? Может раскроете тему в своей статье? А то я смотрю блог «Виртуализация» совсем не пользуется популярностью.
                          • 0
                            В общем и целом — все отлично, и статья хорошая…
                            Однако по моему горькому опыту, инфраструктурные статьи на Хабре практически не пользуются спросом, и с этим ничего нельзя поделать.
                            • +1
                              Ну разумеется — это не «жареная тема» а-ля «запрет видеокамер» или «закрытие хостера в 125 сериях». Но, я думаю, что и таким статьям найдется место на Хабре ;)
                              • 0
                                Ну как знать…
                            • +2
                              Добавлю только одно.

                              ВНИМАНИЕ!!! ВАЖНО!!!

                              Перед объединением (merge) обязательно убедитесь, что на диске с исходным VHD достаточно свободного места по схеме VHD + все последующие AVHD. Иначе потеряете виртуалку. То есть когда кончается место при объединении, вы получаете зависший процесс объединения, и убитый VHD, в который прописалась только часть AVHD.

                              Так же, http://www.networkfoo.org/server-infrastructure/recovering-your-virtual-machine-how-manually-merge-hyper-v-snapshots-back-one-, что делать, если у вас протерялись файлы конфигурациии машины/снепшотов.
                              • 0
                                извиняюсь, хабр съел тэг.
                                • 0
                                  Мегареспект! Добавил в статью.
                                • 0
                                  словами не передать как меня выручил этот комментарий!!!

                                  когда я его дочитал на диске оставалось 5 гб… успел :)
                                • 0
                                  давайте ссылки на остальные статьи
                                • +1
                                  Добавлю 5 копеек.
                                  При откате на снапшот необходимо учитывать несколько моментов:
                                  1. Если виртуальная машина является членом домена, то с момента создания снапшота могли устареть тикеты Kerberos и пароль учётной записи компьютера. Поэтому в лабораторных условиях можно отключать смену паролей учётных записей.
                                  2. Нельзя откатывать назад контроллеры домена! Вообще с контроллерами домена много тонких моментов в виртуальной среде, поэтому рекомендую почитать support.microsoft.com/kb/888794
                                  • 0
                                    Кстати да, с AD там очень много заморочек.
                                    Насчет устаревания тикетов — это правда, именно поэтому снапшоты не рассчитаны на длительное хранение — и в частности поэтому их не рекомендуется использовать вместо бэкапов.
                                    Да, контроллеры домена нельзя откатывать, более того — их не рекомендуется даже переводить в Save State, только Shutdown.
                                  • 0
                                    Привет из будущего.
                                    … и спасибо за полезные статьи по Hyper-V.

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.