company_banner

Об учёте дисков в облаке

    Продолжаем цикл статей, посвящённых учёту ресурсов облака Селектел.

    Процессорное время и память обсуждалась в прошлом году, теперь подошла очередь дисков.

    С диском связаны три ресурса, каждый из которых учитывается отдельно:
    1. хранение дисков
    2. объём прочитанного/записанного
    3. и количество дисковых операций
    Перед тем, как мы обсудим все три ресурса, нужно ещё объяснить одну интересную особенность устройства виртуальных машин — раздельность учёта ресурсов.

    Устройство виртуальной машины

    Процессорное время (то есть процессор) и оперативная память, о которых мы говорили ранее — это неотъемлемые ресурсы виртуальной машины. Если их нет — нет и самой виртуальной машины. Но можно (хотя и сложно) представить себе виртуальную машину без дисков и/или без сетевых интерфейсов. Кроме того, одни и те же диски можно подключать к разным виртуальным машинам. Таким образом возникает вопрос: а как учитывать диски, которые были сначала у одной машины, потом у другой, а сейчас вообще лежат не подключенными?

    Наша ранняя модель учёта подразумевала, что все эти ресурсы относятся на счёт той виртуальной машины, к которой подключены. Но это вызывало массу неоднозначностей, и мы от этой модели отказались, вернувшись к модели, используемой в 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, наоборот, вызовет всплеск активности.
    Selectel
    ИТ-инфраструктура для бизнеса

    Comments 38

      0
      А учет «хранение дисков» Вы производите как?
      По фактически занимаемому месту или по выделенному?
      Скажем, я могу заказать диск на 1TB и занять там 1GB. За что я буду платить? За 1TB или за 1GB?
        +2
        По выделенному.

        Я много думал о возможности аккаунтинга по занятому, но я не знаю ни одного разумного метода обеспечить его для блочного устройства. А файловый доступ требует особой адаптации… Я исследую, но там очень много нюансов.
        –1
        *неотъемлемые — поправьте, пожалуйста.
          0
          спасибо
        • UFO just landed and posted this here
            +3
            Ну, никто не заставляет вникать в подробности — цифра в «итого» идёт в простых и понятных российских рублях.
            • UFO just landed and posted this here
                0
                Мы работаем над этим вопросом, но, давайте я задам вам встречный вопрос:

                Вы перед покупкой телефона или заключением контракта каким образом рассчитываете месячный расход на поминутную оплату? Вы же понимаете, что простыня стоимости звонков на разные международные и междугородние слишком сложна для изучения.
                  +3
                  При покупке телефона я зная куда и сколько я звоню хотя бы приблизительно. Мне нет необходимости подсчитывать количество букв в отправленных и полученных SMS или площадь колебаний осциллограммы голоса. Есть минуты и СМС в 70 кириллических символов.
                  Когда я беру хостинг я знаю сколько места мне надо, сколько оперативной памяти и частоты процессорных ядер. И я ваще не в курсе сколько у меня там миллионов операций чтения диска или расход памяти в ТБ часах… Чтобы узнать сколько будет стоить ваш хостинг для моих нужд мне нужна целая лаборатория!
                    +1
                    А кто вам мешает посмотреть это? Кто-то из жителей планеты не знает, сколько нужно процессора для его хостинга. Кто-то не может хотя бы на вскидку в atop'е посмотреть на текущую загрузку диска по числу операций или график мунина для среднего.

                    Что вы от нас ожидаете? Пообещать всем «сколько хотите дисковых операций — все ваши»? Но в этом случае любитель торрентов будет наслаждаться быстрыми и дешёвыми дисками, а владелец нормального сайта — возмущаться тем, какой дорогой у него диск.

                    Это реальный мир — либо у нас уравниловка, либо аренда железки (кстати, это мы делаем), либо у нас честная оплата только своей части нагрузки.

                    Относительно же учёта памяти я совсем в недоумении. Неужели трудно «знаю… сколько оперативной памяти» поделить на 1000 и умножить на 24?
                      0
                      Сделайте калькулятор
                        0
                        При создании машины показывается минимальный объём потребления на основании дискового пространства и минимальной границы памяти.
                          0
                          Ок, надо пробовать, с ходу мало что понятно… с другими облаками легче :)
            • UFO just landed and posted this here
                +2
                А по-моему все просто. Перемножаете цену на предполагаемое количество каждого ресурса, суммируете и получаете стоимость аренды.
                  +3
                  Точный учет и оплата по реально потребеленным ресурсам — это ОЧЕНЬ правильный подход! Это:
                  а) справедливость (иначе всегда есть элемент уравниловки, когда вы платите частично за соседа)
                  б) четкие правила игры, понятные пути экономии и оптимизации.

                  Я помню, когда у нас ГТС вводила повременку, столько хая было, особенно в рядах пенсионеров! Одна тетка на работе мне рассказывала, что их «дети делают уроки по телефону с друзьями! а как теперь?!» Вопрос, почему Я должен оплачивать безлимитную болтовню ЕЁ ребенка, ей в голову не приходил.

                  Точная и раздельная тарификация это очень правильно — в принципе. Другой вопрос, что численно тарифы должны быть разумными, а это бывает не у всех. Например, у наших местных интернет-провайдеров оплата по трафику вместо анлима очень невыгодна любому, кто делает в инете хоть что-то сверх переписки аськи и пары писем в день. Те тарифы совершенно не отражают современные интернет-реалии. Но беря анлим для работы, я дотирую адских торренто-качальщиков, высасывающих из линии на порядок больше, а платящих столько же. Лично я бы с удовольствием взял помегабайтный тариф с реалистичной ценой мегабайта.
                    +2
                    Я хоть и не минусовал, но аргументирую :)

                    Самая дешевая система — это самая дотошная в подсчетах затрат система. Чем больше допущений и округлений, тем дороже выходит для тех, кто потребляет мало. А для тех, кто потребляет много, как правило дешевле не выходит.

                    Селектел, на сколько я вижу, стараются сделать так, чтобы учет ресурсов шел максимально приближенно к их реальному потреблению — а значит минимум переплат. И у них реально дешевле (пока) получилось, в сравнении с российским конкурентом (я только клодо знаю), если нагрузки минимальные. А это хорошая доля рынка.

                    Как-то так :)
                      0
                      Скажу так, для людей, которые будут стабильно потреблять больше ~50% ресурсов хоста, безусловно, выгоднее просто этот хост взять в аренду.

                      А теперь вопрос: вы уверены, что сумеете на 50% загрузить 8 ядер зеона, по делу сожрать несколько десятков гигабайт памяти, забить под потолок 10 мегабит (у нас по-умолчанию на арендованный сервер 10 Мб, большая полоса — выше. На облаке у всех гигабит с шаред на всех 10Г аплинками) и загрузить полностью диски?

                      Если нет, то облако оказывается интереснее. 11.5т.р. (цена аренды зеоновской машины) — это 380р в сутки, а по моим наблюдениям, без учёта инета, не выедает никто.
                    0
                    В большой по кол-ву серверов американской компании (еще год назад — 18 датацентров), стоит SCOM Server. Для учета фактического использования места на винтах, exchange, mssql мной с (с командой) были написаны специальные management packs. Это не лучший вариант, но рабочий.
                      0
                      А иопсы как считали? Учет фактического места на винтах, особенно для эксченджа и сиквела мало что дает.
                        0
                        Иопсы не считали.
                        У них не настолько продвинутый биллинг.

                        Можно получать значения performance counter'ов.
                        Из SCOM можно запускать powershell, vbscript, дергать произвольные COM компоненты и .net сборки.
                      +1
                      не в состоянии дать гостевой доступ, дайте лояльную форму регистрации
                        +2
                        Насчёт формы регистрации — это зависит не от нас. Мы работаем в «белую» и, к сожалению, все требования регулирующих органов мы выполняем. Я уже кому-то говорил, что если бы мы это делали без оглядки на существование юр.лица в российских реалиях, то форма бы выглядела как «емейл + зарегистрироваться» или вообще, вход по openID. Но — мы обязаны.

                        Относительно же гостевого доступа ответ простой: если мы делаем гостевой доступ, то его кто-то будет оплачивать. Например, клиенты. Зачем нам делать клиентам дороже?
                          +2
                          комментировать не буду. сделайте промо-ролик
                            0
                            О, а вот за идею спасибо. Да, наверное, сделаю. Осталось найти приятный голос для озвучки.
                        0
                        спасибо за такие статьи… очень легко читается и познавательно… аффтар пишы исчо =)
                        лю я (пара)виртуализацию… что поделать
                          0
                          А в чем суть учета IOPS? неужели это такой ресурс на учет которого можно забить заложив ~стоимость в стоимость дискового пространства?
                            0
                            О, это, действительно, такой ресурс.
                            Поясню: допустим, у меня на сайте 5 Гб картинок и 100 посетителей в день, а у соседа 5 Гб видео и 1000 посетителей их активно смотрят. Хостинг либо берет со всех больше, либо соседа выгоняет на дедикейтед.
                              0
                              Можно. Известна производительность диска. Известна средняя нагрузка с клиента. Делим одно на другое — получаем количество клиентов на диск. Дальше пропрорционально рассчитывается стоимость гигабайта.

                              В случае с платными иопсами тот, кто их делает будет платить больше, а тот, кто не делает — меньше. И сможет арендовать малоиспользуемое обширное место за разумные деньги, в сумму которых не заложены торренты и прочие ужасы.
                                0
                                Ясно. Меня просто пугали всегда платные IOPS казалось, что буду платить больше.
                                  0
                                  Больше чем что? Чем «в среднем»? Но тут есть тонкий момент: среднее число иопсов считается как «сумма/пользователи». При этом те, кто сильно нагружает диск смещают среднее вверх так, что большинство пользователей потребляет меньше среднего (да, парадокс).

                                  По цифрам: три случайно выбранные машины, статистика за сутки:
                                  Машинное время	0,31 руб. / 0.310 час.
                                  Потребление памяти	6,10 руб. / 12.278 Гб * час.
                                  Диск: запросов на чтение	0,04 руб. / 0.012 млн. шт.
                                  Диск: запросов на запись	0,23 руб. / 0.069 млн. шт.
                                  Диск: прочитанный объём	0,04 руб. / 0.400 Гб
                                  Диск: записанный объём	0,05 руб. / 0.500 Гб
                                  Диск: хранение	4,79 руб. / 0.959 Тб * час
                                  Сеть: получено	0,03 руб. / 0.150 Гб
                                  Сеть: отправлено	1,66 руб. / 1.660 Гб
                                  Итого	13,25 руб
                                  


                                  Машинное время	0,26 руб. / 0.260 час.
                                  Потребление памяти	1,52 руб. / 3.060 Гб * час.
                                  Диск: запросов на чтение	0,00 руб. / 0.000 млн. шт.
                                  Диск: запросов на запись	0,16 руб. / 0.048 млн. шт.
                                  Диск: прочитанный объём	0,00 руб. / 0.000 Гб
                                  Диск: записанный объём	0,03 руб. / 0.300 Гб
                                  Диск: хранение	0,24 руб. / 0.048 Тб * час
                                  Сеть: получено	0,01 руб. / 0.050 Гб
                                  Сеть: отправлено	0,06 руб. / 0.060 Гб
                                  Итого	2,28 руб
                                  


                                  Машинное время	0,27 руб. / 0.270 час.
                                  Потребление памяти	12,20 руб. / 24.557 Гб * час.
                                  Диск: запросов на чтение	0,00 руб. / 0.000 млн. шт.
                                  Диск: запросов на запись	0,14 руб. / 0.042 млн. шт.
                                  Диск: прочитанный объём	0,00 руб. / 0.000 Гб
                                  Диск: записанный объём	0,03 руб. / 0.300 Гб
                                  Диск: хранение	7,67 руб. / 1.535 Тб * час
                                  Сеть: получено	0,01 руб. / 0.050 Гб
                                  Сеть: отправлено	0,00 руб. / 0.000 Гб
                                  Итого	20,32 руб.
                                  


                                  Чем они там занимаются — не имею ни малейшего представления, просто случайные машины из списка.
                                    0
                                    Дело в том, что для меня IOPS была такая абстрактная величика и проверить сколько я буду потреблять у меня не было возможности. Все физические сервера у меня выполняют сразу много функций и выделить кол-во IOPS я не мог. Поэтому я предпочитал фиксированую оплату в месяц.

                                    Сейчас-то я понимаю, что мне хватает 2х микро инстанса на амазоне + оплата перерасходы 2-4$ в месяц.
                                      0
                                      Это в сутки?
                                        0
                                        Ага.
                                0
                                Будет удешевление оперативной памяти, все таки плашки памяти сегодня существенно подешевели.
                                  0
                                  Я думаю, тут дело не в стоимости планок, а в том, что планки вставляются в сервера. И память обычно утилизируется лучше всего.
                                  0
                                  Вот читаю, всё выглядит очень привлекательно. Уже регистрируюсь.
                                  Но уже на этапе регистрации захотелось выразить своё «фи»: для регистрации нужны паспортные данные (с этим я не спорю), но эти данные предлагается ввести в форму без https.
                                    0
                                    После долгого флейма, вроде удалось размазать регистрацию (она будет по мере надобности данных для разных услуг), в планы по переработке внесено.

                                    А вот насчёт https спасибо, поднял баг в багтрекере, поправим в ближайшие день-два.

                                  Only users with full accounts can post comments. Log in, please.