Продолжаем подробный разбор того, как учитываются ресурсы.
Перед тем, как мы обсудим, как учитывается память, сначала посмотрим, как эта память виртуальной машине выделяется, и что такое вообще «память виртуальной машины».
С точки зрения Xen'а выделение памяти домену (виртуальной машине) означает, что домен имеет право писать в указанную страницу памяти. Попытка домена записать в запрещённую для него страницу памяти вызовет исключительную ситуацию и с большой вероятностью прекращение работы домена, так что ядро гостевой системы тщательно следит за тем, чтобы не выйти за пределы разрешённой памяти (ровно так же, если программа попытается обратиться к несуществующей странице памяти, то ядро программу аварийно завершит или вызовет обработчик ошибок). В любом случае, виртуальной машине разрешено использовать только ту память, которую ей разрешили использовать. Таким образом, Xen всегда точно знает, сколько страниц памяти выделено той или иной виртуальной машине. (Да, минимальная градация учёта памяти — это 4кб кусочек памяти, называющийся «страница»). Я опущу раздел, связанный с трансляциями адресов, поскольку это одна из самых… м… затруднительных областей. Если вкратце — пририсуйте к обычной схеме трансляции виртуальной памяти на i386 ещё две таблицы дескрипторов — получится примерно оно.
Когда домен создаётся (то есть виртуальная машина стартует), программа под названием domain_builder говорит Xen'у, сколько страниц нужно выделить домену. Эту же информацию сообщают ядру гостевой системы, чтобы оно знало, сколько ей памяти выделено.
Внутри виртуальной машины запущен modd (memory on demand dæmon), который посредством xenstore (специфичный для зена метод взаимодействия между доменами) сообщает управляющему сервису о том, в каком состоянии находится память домена. В реальности это просто запись содержимого /proc/meminfo, не более. Сервер смотрит на настройки виртуальной машины и решает, сколько памяти нужно добавить или убрать. И отдаёт команду на изменение памяти.
И вот тут начинается самое интересное. В Xen'е существует понятие передача страниц памяти. Это, в буквальном смысле, означает «взять страницу памяти от одного домена и передать другому». Соответственно, когда отдаётся команда на отдачу/приём памяти, Xen забирает у гостевой системы память, или отдаёт ей эту память. В силу общей (полезной) параноидальности Xen'а, все отдаваемые из домена страницы предварительно обнуляются (чтобы случайно не отдать ценные данные посторонним соседям по виртуализации).
Понятно, что память имеет границы уменьшения — ядро и базовые программы (init, getty и т.д.) хотят себе какой-то объём памяти. Ниже него спускаться нельзя, а приближаться опасно (можно «чуть-чуть» пережать и вызвать OOM или другие неприятные проблемы). Именно это объясняет довольно высокий нижний лимит памяти.
С верхним лимитом всё сложнее. При создании домена (старте виртуальной машины) задаётся верхняя граница памяти, и запускающаяся машина резервирует себе определённый объём служебных данных под возможные «будущие» страницы. Это не очень большой объём, но он всё-таки есть, и высокая верхняя граница памяти увеличивает потребление памяти. Потому официальная рекомендация не делать соотношение минимум/максимум больше 8-10. В теории, когда будет полностью стабильно отлажена работа memory hotplug этот лимит будет снят, но в настоящий момент технология слишком экспериментальная, чтобы брать за неё деньги.
Таким образом, память меняется автоматически в заданных пределах. О MOD мы поговорим ещё, после того, как наши программисты таки доделают возможность клиентам менять настройки MOD.
Но, в рамках общего любопытства, отвечу о том, что произойдёт, если MOD выключить. Память просто перестанет регулироваться (она зафксируется на том объёме, который был, и на этом всё успокоится). Учёт памяти никак не связан с MOD.
Понятно, что классическое VDS'ное «XXX мегабайт в месяц» (прямая линия на картинке справа) не подходит — сейчас это 256 мегабайт, а через десять секунд — уже 500, а то и пара гигабайт.
Вместо этого мы учитываем величину под названием Гб*ч, то есть гигабайт в час. На самом деле, внутренней единицей учёта у нас является kb*ns (килобайт-наносекунда), но цена килобайт-секунды слишком маленькая, и писать её в прайсе — сбивать людей с толку, не говоря уже о бухгалтерах, пугающихся цифр вида «цена 1.3*10-19руб», или, ещё лучше, «количество: 10e+23», так что в интерфейсе мы приводим эту величину к разумной цифре (Гб * ч). Но внутренний учёт аналогичен тому, как мы делаем с процессором — деньги за память снимаются, как только набежала копейка или более.
Гб*ч — величина синтетическая. Это может быть 128 Мб, растянутые на 8 часов, или 4 Гб за 15 минут, или комбинация изменяющихся объёмов памяти, сложенная соответствующим образом. На картинках показаны разные случаи использования памяти. Во всех картинках показан интервал в час астрономического времени.
Теперь о том, как мы суммируем. Раз в небольшой интервал времени мы берём значение памяти, умножаем на длительность интервала, получаем количество kb*s за этот интервал. Эти величины суммируются, вне зависимости от того, на каком хосте находится машина. Кстати, там же собирается и статистика (для графиков), но нам очень не хватает программистов (мы серьёзно — у нас открыты вакансии программистов и мы ждём вас), так что в интерфейсе у клиентов это появится позже. По сути, это простейшее числовое интегрирование кривой выделения памяти, аппроксимированное прямоугольниками. Для избежания неприятных эффектов мы отбрасываем первое и последнее значение, так что можете считать, что 2 секунды использования памяти за весь срок жизни машины мы вам дарим.
Ещё одним вопросом, часто возникающим, является вопрос о том, какую память мы считаем. Если внимательно присмотреться к данным /proc/meminfo или выводу ps, можно увидеть кучу разных значений. К счастью, все эти значения, включая размер адресного пространства, это лишь «собственные выдумки» ядра гостевой системы. Есть величина выделенной памяти (totalmem), она указывает на то, сколько физических страниц памяти выделено виртуальной машине.
Кстати, я забыл сказать. В Xen'е нет оверселла. Что такое оверселл? Это когда 10 виртуальным машинам говорят «вот тебе 500 Мб», а на ноде (сервере, делающем виртуализацию) есть всего 2Гб. Смешно? Но так живёт любой хост под openVZ. Так как программы редко забивают 100% оперативной памяти, остатки «перепродаются» (англ. oversell) ещё раз. В большинстве случаев это хорошо, но что делать, если все десять машин заняли по 400Мб? Беда. Так вот, Xen не имеет режима оверселла, и более того, модель работы с памятью в Xen'е в принципе не допускает ситуации «обещанной, но не выделенной» оперативной памяти. Есть весьма специфичные ситуации «общих» страниц памяти (они используются в драйверах и счёт идёт на единицы килобайт), но ситуаций, чтобы страницы памяти приложений (а не драйверов) были общими между разными виртуальными машинами не бывает. Вся выделенная память для виртуальной машины принадлежит ей и только ей. Даже если эта память не используется.
Собственно, возвращаемся к свободной памяти. Ядро линукса известно своей жадностью к памяти — вся свободная память занимается дисковым кешем. Мы об этом поговорим чуть позже, но дисковый кеш в облаке — очень полезная штука, так как позволяет существенно уменьшить количество дисковых операций (особенно, чтения). Свободная память может быть только на очень простаивающей машине с избыточным запасом памяти. Мы стараемся обеспечить такой режим работы, чтобы «совсем свободной» памяти не было. Хотя, если виртуальная машина простаивает, ситуация, когда занято 60 из 128 Мб вполне возможна. Мы учитываем всю выделенную память домену — и да, свободная и простаивающая память учитывается, поскольку она была выделена в эксклюзивное пользование домену.
Теперь немного о swap-файле, файле подкачки (точнее, чаще всего это раздел подкачки). swap очень полезен для гостевой системы — он позволяет ядру увеличить размер виртуальной памяти. При влюченном MOD единственное назначение файла подкачки — увеличение виртуальной памяти (фактически, это «оверселл», который устраивает ядро для процессов в гостевой машине). Кроме того, он страхует от внезапных скачков памяти. MOD реагирует довольно шустро (время реакции меньше секунды), однако, в определённых условиях (например, кто-то попросил много памяти) может не успеть. В этом случае файл подкачки позволит разрулить ситуацию, запрос будет успешен, а подоспевший MOD обеспечит нужный объём памяти). Кроме того, ситуация, когда у работающей машины часть процессов оказывается вытеснена в swap-файл нормальна — это естественная оптимизация использования памяти. Например, CentOS (на мой взгляд, довольно толстая и перегруженная фенечками система) запускает довольно много демонов, приличная часть которых не используется большую часть времени. Такие демоны вытесняются в файл подкачки и лежат там неделями без движения.
Отключение файла подкачки мы очень не советуем, так как денег это существенно не сэкономит, а вот риски нарваться на сообщение MemoryError в момент некрасивого взбрыка с запросом памяти от толстого приложения сильно увеличиваются. Более того, если оказывается так, что много процессов резервируют себе много виртуальной памяти, мы советуем, наоборот, увеличить объём файла подкачки (например, создав и подключив второй) — это даст больше свободы для операционной системы по управлению адресным пространством.
Перед тем, как мы обсудим, как учитывается память, сначала посмотрим, как эта память виртуальной машине выделяется, и что такое вообще «память виртуальной машины».
Реальная память виртуальных машин
Гипервизор Xen, являющийся основой XCP, являющийся основой облака Селектел, контролирует несколько аспектов работы виртуальных машин. Из интересующих нас с точки зрения учёта — процессор и память. Процессор мы обсудили, теперь очередь оперативной памяти.С точки зрения Xen'а выделение памяти домену (виртуальной машине) означает, что домен имеет право писать в указанную страницу памяти. Попытка домена записать в запрещённую для него страницу памяти вызовет исключительную ситуацию и с большой вероятностью прекращение работы домена, так что ядро гостевой системы тщательно следит за тем, чтобы не выйти за пределы разрешённой памяти (ровно так же, если программа попытается обратиться к несуществующей странице памяти, то ядро программу аварийно завершит или вызовет обработчик ошибок). В любом случае, виртуальной машине разрешено использовать только ту память, которую ей разрешили использовать. Таким образом, Xen всегда точно знает, сколько страниц памяти выделено той или иной виртуальной машине. (Да, минимальная градация учёта памяти — это 4кб кусочек памяти, называющийся «страница»). Я опущу раздел, связанный с трансляциями адресов, поскольку это одна из самых… м… затруднительных областей. Если вкратце — пририсуйте к обычной схеме трансляции виртуальной памяти на i386 ещё две таблицы дескрипторов — получится примерно оно.
Когда домен создаётся (то есть виртуальная машина стартует), программа под названием domain_builder говорит Xen'у, сколько страниц нужно выделить домену. Эту же информацию сообщают ядру гостевой системы, чтобы оно знало, сколько ей памяти выделено.
Внутри виртуальной машины запущен modd (memory on demand dæmon), который посредством xenstore (специфичный для зена метод взаимодействия между доменами) сообщает управляющему сервису о том, в каком состоянии находится память домена. В реальности это просто запись содержимого /proc/meminfo, не более. Сервер смотрит на настройки виртуальной машины и решает, сколько памяти нужно добавить или убрать. И отдаёт команду на изменение памяти.
И вот тут начинается самое интересное. В Xen'е существует понятие передача страниц памяти. Это, в буквальном смысле, означает «взять страницу памяти от одного домена и передать другому». Соответственно, когда отдаётся команда на отдачу/приём памяти, Xen забирает у гостевой системы память, или отдаёт ей эту память. В силу общей (полезной) параноидальности Xen'а, все отдаваемые из домена страницы предварительно обнуляются (чтобы случайно не отдать ценные данные посторонним соседям по виртуализации).
Понятно, что память имеет границы уменьшения — ядро и базовые программы (init, getty и т.д.) хотят себе какой-то объём памяти. Ниже него спускаться нельзя, а приближаться опасно (можно «чуть-чуть» пережать и вызвать OOM или другие неприятные проблемы). Именно это объясняет довольно высокий нижний лимит памяти.
С верхним лимитом всё сложнее. При создании домена (старте виртуальной машины) задаётся верхняя граница памяти, и запускающаяся машина резервирует себе определённый объём служебных данных под возможные «будущие» страницы. Это не очень большой объём, но он всё-таки есть, и высокая верхняя граница памяти увеличивает потребление памяти. Потому официальная рекомендация не делать соотношение минимум/максимум больше 8-10. В теории, когда будет полностью стабильно отлажена работа memory hotplug этот лимит будет снят, но в настоящий момент технология слишком экспериментальная, чтобы брать за неё деньги.
Таким образом, память меняется автоматически в заданных пределах. О MOD мы поговорим ещё, после того, как наши программисты таки доделают возможность клиентам менять настройки MOD.
Но, в рамках общего любопытства, отвечу о том, что произойдёт, если MOD выключить. Память просто перестанет регулироваться (она зафксируется на том объёме, который был, и на этом всё успокоится). Учёт памяти никак не связан с MOD.
Учёт памяти
Понятно, что классическое VDS'ное «XXX мегабайт в месяц» (прямая линия на картинке справа) не подходит — сейчас это 256 мегабайт, а через десять секунд — уже 500, а то и пара гигабайт.Вместо этого мы учитываем величину под названием Гб*ч, то есть гигабайт в час. На самом деле, внутренней единицей учёта у нас является kb*ns (килобайт-наносекунда), но цена килобайт-секунды слишком маленькая, и писать её в прайсе — сбивать людей с толку, не говоря уже о бухгалтерах, пугающихся цифр вида «цена 1.3*10-19руб», или, ещё лучше, «количество: 10e+23», так что в интерфейсе мы приводим эту величину к разумной цифре (Гб * ч). Но внутренний учёт аналогичен тому, как мы делаем с процессором — деньги за память снимаются, как только набежала копейка или более.
Гб*ч — величина синтетическая. Это может быть 128 Мб, растянутые на 8 часов, или 4 Гб за 15 минут, или комбинация изменяющихся объёмов памяти, сложенная соответствующим образом. На картинках показаны разные случаи использования памяти. Во всех картинках показан интервал в час астрономического времени.
Теперь о том, как мы суммируем. Раз в небольшой интервал времени мы берём значение памяти, умножаем на длительность интервала, получаем количество kb*s за этот интервал. Эти величины суммируются, вне зависимости от того, на каком хосте находится машина. Кстати, там же собирается и статистика (для графиков), но нам очень не хватает программистов (мы серьёзно — у нас открыты вакансии программистов и мы ждём вас), так что в интерфейсе у клиентов это появится позже. По сути, это простейшее числовое интегрирование кривой выделения памяти, аппроксимированное прямоугольниками. Для избежания неприятных эффектов мы отбрасываем первое и последнее значение, так что можете считать, что 2 секунды использования памяти за весь срок жизни машины мы вам дарим.
Дисковый кеш, свободная память и своп
Ещё одним вопросом, часто возникающим, является вопрос о том, какую память мы считаем. Если внимательно присмотреться к данным /proc/meminfo или выводу ps, можно увидеть кучу разных значений. К счастью, все эти значения, включая размер адресного пространства, это лишь «собственные выдумки» ядра гостевой системы. Есть величина выделенной памяти (totalmem), она указывает на то, сколько физических страниц памяти выделено виртуальной машине.
Кстати, я забыл сказать. В Xen'е нет оверселла. Что такое оверселл? Это когда 10 виртуальным машинам говорят «вот тебе 500 Мб», а на ноде (сервере, делающем виртуализацию) есть всего 2Гб. Смешно? Но так живёт любой хост под openVZ. Так как программы редко забивают 100% оперативной памяти, остатки «перепродаются» (англ. oversell) ещё раз. В большинстве случаев это хорошо, но что делать, если все десять машин заняли по 400Мб? Беда. Так вот, Xen не имеет режима оверселла, и более того, модель работы с памятью в Xen'е в принципе не допускает ситуации «обещанной, но не выделенной» оперативной памяти. Есть весьма специфичные ситуации «общих» страниц памяти (они используются в драйверах и счёт идёт на единицы килобайт), но ситуаций, чтобы страницы памяти приложений (а не драйверов) были общими между разными виртуальными машинами не бывает. Вся выделенная память для виртуальной машины принадлежит ей и только ей. Даже если эта память не используется.
Собственно, возвращаемся к свободной памяти. Ядро линукса известно своей жадностью к памяти — вся свободная память занимается дисковым кешем. Мы об этом поговорим чуть позже, но дисковый кеш в облаке — очень полезная штука, так как позволяет существенно уменьшить количество дисковых операций (особенно, чтения). Свободная память может быть только на очень простаивающей машине с избыточным запасом памяти. Мы стараемся обеспечить такой режим работы, чтобы «совсем свободной» памяти не было. Хотя, если виртуальная машина простаивает, ситуация, когда занято 60 из 128 Мб вполне возможна. Мы учитываем всю выделенную память домену — и да, свободная и простаивающая память учитывается, поскольку она была выделена в эксклюзивное пользование домену.
Теперь немного о swap-файле, файле подкачки (точнее, чаще всего это раздел подкачки). swap очень полезен для гостевой системы — он позволяет ядру увеличить размер виртуальной памяти. При влюченном MOD единственное назначение файла подкачки — увеличение виртуальной памяти (фактически, это «оверселл», который устраивает ядро для процессов в гостевой машине). Кроме того, он страхует от внезапных скачков памяти. MOD реагирует довольно шустро (время реакции меньше секунды), однако, в определённых условиях (например, кто-то попросил много памяти) может не успеть. В этом случае файл подкачки позволит разрулить ситуацию, запрос будет успешен, а подоспевший MOD обеспечит нужный объём памяти). Кроме того, ситуация, когда у работающей машины часть процессов оказывается вытеснена в swap-файл нормальна — это естественная оптимизация использования памяти. Например, CentOS (на мой взгляд, довольно толстая и перегруженная фенечками система) запускает довольно много демонов, приличная часть которых не используется большую часть времени. Такие демоны вытесняются в файл подкачки и лежат там неделями без движения.
Отключение файла подкачки мы очень не советуем, так как денег это существенно не сэкономит, а вот риски нарваться на сообщение MemoryError в момент некрасивого взбрыка с запросом памяти от толстого приложения сильно увеличиваются. Более того, если оказывается так, что много процессов резервируют себе много виртуальной памяти, мы советуем, наоборот, увеличить объём файла подкачки (например, создав и подключив второй) — это даст больше свободы для операционной системы по управлению адресным пространством.
