Продолжаем цикл статей, посвящённых учёту ресурсов облака Селектел.
Процессорное время и память обсуждалась в прошлом году, теперь подошла очередь дисков.
С диском связаны три ресурса, каждый из которых учитывается отдельно:
Процессорное время (то есть процессор) и оперативная память, о которых мы говорили ранее — это неотъемлемые ресурсы виртуальной машины. Если их нет — нет и самой виртуальной машины. Но можно (хотя и сложно) представить себе виртуальную машину без дисков и/или без сетевых интерфейсов. Кроме того, одни и те же диски можно подключать к разным виртуальным машинам. Таким образом возникает вопрос: а как учитывать диски, которые были сначала у одной машины, потом у другой, а сейчас вообще лежат не подключенными?
Наша ранняя модель учёта подразумевала, что все эти ресурсы относятся на счёт той виртуальной машины, к которой подключены. Но это вызывало массу неоднозначностей, и мы от этой модели отказались, вернувшись к модели, используемой в Xen Cloud Platform. На картинке упрощённая версия этой модели. Синим показано то, что принадлежит пользователю, зелёным — имена объектов, у которых осуществляется учёт.
В новой модели учёт полностью раздельный, для каждой компоненты потребление считается отдельно. Для удобства вывода пользователю эти величины суммируются и показываются так, как будто относятся к одной машине, но на самом деле у виртуальной машины есть только два собственных ресурса для учёта — это процессор и память. Оставшиеся компоненты — диск и сеть образуют три отдельные сущности (я не оговорился — три). Это VDI, VBD и VIF. (Virtual Disk Image, Virtual Block Device, Virtual Network Interface). Если с VIF всё ясно, то с VDI/VBD не совсем. Зачем их два?
Дело в том, что VDI — это лишь «место на диске». Оно не связано с какой-либо машиной, оно ничего не знает про операции чтения/записи. Объектом учёта у VDI выступает лишь одна величина — «хранение». Для примера на рисунке один диск (VDI) не подключен к машине — он только хранится.
А вот VBD — это как раз драйвер, который осуществляет дисковые операции. Именно он считает количество операций и объём прочитанных/записанных данных. VBD связывает между собой VDI и VM (виртуальную машину).
Каждый раз, когда диск подключается к виртуальной машине создаётся новый VBD.
Просто? Да. Сложности начинаются дальше, когда мы пытаемся понять, «а когда именно произойдут дисковые операции?» Разработчики ядра линукса потратили огромное время на отлаживание и совершенствование алгоритма кеширования — и оно работает. Как показывает статистика, чем более нагружена машина, тем больше у неё запросов на запись в сравнении с запросами на чтение. И наоборот, чем менее нагружена машина, тем больше некешированных запросов на чтение (в процентах, разумеется) по сравнению с запросами на запись из-за того, что почти каждый файл читается «в первый раз» (с момента загрузки).
Собственно, вот реальные цифры: по всему облаку у нас соотношение операций чтения к операциям записи составляет 3/4. На первой попавшейся машине с потреблением менее 5 р/сутки соотношение запись к чтению — 2:1, если быть точным, 2.2 миллиона к 1.1 миллиона. А на очень серьёзно загруженной машине (около 450р/сутки) соотношение чтение/запись 0.3 миллиона к 4 миллионам (большая часть расходов машины — это исходящий трафик, больше 300 Гб/сутки). Вполне очевидно, что отдать 300Гб из ниоткуда невозможно, так что это то место, где хорошо работает дисковое кеширование. (Кстати, упреждая вопрос о том, зачем у нас такой большой запас памяти у MOD — именно для подобного кеширования).
Таким образом предсказать создаст ли конкретная файловая операция какие-либо действия с блочным устройством невозможно. Хотя можно предсказать, что первое чтение файла вызовет операцию чтения, а повторное чтение — с некоторой вероятностью, нет.
Сразу упреждаю вопросы, которые периодически появляются в тикетах: любые операции с виртуальными файловыми системами (/proc, /sys), подмонтированными nfs-шарами, iscsi-устройствами, diskless drbd-шарами и т.д. не являются объектом учёта — учитываются только обращения к /dev/xvd* устройствам. Очевидно, что и всякие операции с fifo, unix sockets и т.д. так же не вызывают дисковых операций. А вот банальная команда sync, наоборот, вызовет всплеск активности.
Процессорное время и память обсуждалась в прошлом году, теперь подошла очередь дисков.
С диском связаны три ресурса, каждый из которых учитывается отдельно:
- хранение дисков
- объём прочитанного/записанного
- и количество дисковых операций
Устройство виртуальной машины
Процессорное время (то есть процессор) и оперативная память, о которых мы говорили ранее — это неотъемлемые ресурсы виртуальной машины. Если их нет — нет и самой виртуальной машины. Но можно (хотя и сложно) представить себе виртуальную машину без дисков и/или без сетевых интерфейсов. Кроме того, одни и те же диски можно подключать к разным виртуальным машинам. Таким образом возникает вопрос: а как учитывать диски, которые были сначала у одной машины, потом у другой, а сейчас вообще лежат не подключенными?Наша ранняя модель учёта подразумевала, что все эти ресурсы относятся на счёт той виртуальной машины, к которой подключены. Но это вызывало массу неоднозначностей, и мы от этой модели отказались, вернувшись к модели, используемой в Xen Cloud Platform. На картинке упрощённая версия этой модели. Синим показано то, что принадлежит пользователю, зелёным — имена объектов, у которых осуществляется учёт.
В новой модели учёт полностью раздельный, для каждой компоненты потребление считается отдельно. Для удобства вывода пользователю эти величины суммируются и показываются так, как будто относятся к одной машине, но на самом деле у виртуальной машины есть только два собственных ресурса для учёта — это процессор и память. Оставшиеся компоненты — диск и сеть образуют три отдельные сущности (я не оговорился — три). Это VDI, VBD и VIF. (Virtual Disk Image, Virtual Block Device, Virtual Network Interface). Если с VIF всё ясно, то с VDI/VBD не совсем. Зачем их два?
Дело в том, что VDI — это лишь «место на диске». Оно не связано с какой-либо машиной, оно ничего не знает про операции чтения/записи. Объектом учёта у VDI выступает лишь одна величина — «хранение». Для примера на рисунке один диск (VDI) не подключен к машине — он только хранится.
А вот VBD — это как раз драйвер, который осуществляет дисковые операции. Именно он считает количество операций и объём прочитанных/записанных данных. VBD связывает между собой VDI и VM (виртуальную машину).
Каждый раз, когда диск подключается к виртуальной машине создаётся новый VBD.
Что такое «дисковая операция»?
С точки зрения линукса VBD — такое же блочное устройство, как и множество других, со своим драйвером, предоставляющим стандартный интерфейс. /dev/xvda ничем не отличается от /dev/sda или /dev/hda. Когда операционная система хочет что-то прочитать или записать, она обращается к драйверу блочного устройства с соответствующей командой.Просто? Да. Сложности начинаются дальше, когда мы пытаемся понять, «а когда именно произойдут дисковые операции?» Разработчики ядра линукса потратили огромное время на отлаживание и совершенствование алгоритма кеширования — и оно работает. Как показывает статистика, чем более нагружена машина, тем больше у неё запросов на запись в сравнении с запросами на чтение. И наоборот, чем менее нагружена машина, тем больше некешированных запросов на чтение (в процентах, разумеется) по сравнению с запросами на запись из-за того, что почти каждый файл читается «в первый раз» (с момента загрузки).
Собственно, вот реальные цифры: по всему облаку у нас соотношение операций чтения к операциям записи составляет 3/4. На первой попавшейся машине с потреблением менее 5 р/сутки соотношение запись к чтению — 2:1, если быть точным, 2.2 миллиона к 1.1 миллиона. А на очень серьёзно загруженной машине (около 450р/сутки) соотношение чтение/запись 0.3 миллиона к 4 миллионам (большая часть расходов машины — это исходящий трафик, больше 300 Гб/сутки). Вполне очевидно, что отдать 300Гб из ниоткуда невозможно, так что это то место, где хорошо работает дисковое кеширование. (Кстати, упреждая вопрос о том, зачем у нас такой большой запас памяти у MOD — именно для подобного кеширования).
Таким образом предсказать создаст ли конкретная файловая операция какие-либо действия с блочным устройством невозможно. Хотя можно предсказать, что первое чтение файла вызовет операцию чтения, а повторное чтение — с некоторой вероятностью, нет.
Сразу упреждаю вопросы, которые периодически появляются в тикетах: любые операции с виртуальными файловыми системами (/proc, /sys), подмонтированными nfs-шарами, iscsi-устройствами, diskless drbd-шарами и т.д. не являются объектом учёта — учитываются только обращения к /dev/xvd* устройствам. Очевидно, что и всякие операции с fifo, unix sockets и т.д. так же не вызывают дисковых операций. А вот банальная команда sync, наоборот, вызовет всплеск активности.
