Жизненный цикл услуг в Cloud2/Premium

При разработке Cloud2/Premium мы реализовали подход к созданию виртуальных машин, основанный на проектах и заказанных ресурсах. У некоторых пользователей возникают вопросы по его использованию, поэтому мы написали эту статью. Изложение статьи будет происходить в духе комментирования картинки жизненного цикла услуг, которую вы можете видеть далее. Все важные элементы сопровождаются числовым кодом, который мы и будем использовать при дальнейшем изложении материала.


Начало работы с Cloud2
Итак, взглянем на шаг (1). У пользователя есть учетная запись в биллинге — системе, которая управляет услугами, позволяет пополнять счет и списывает средства. Далее, пользователь создает аккаунт в Cloud2 и заказывает при создании 2 GB RAM, 20 GB дискового пространства и 40 GB пространства для снимков. В биллинге появляется проект с пользовательской меткой «Project 1» и системным именем «accountXXXXX», где «account» — имя учетной записи в биллинге, а XXXXX — номер услуги (2).

У пользователя еще нет виртуальных машин, он просто заказал ресурсы.

Теперь наш пользователь может войти в панель управления Cloud2 (2.1), которая ему стала доступна (смотрите Урок 1 за подробностями). В панели он решил создать две виртуальные машины с памятью 1 GB и диском 10 GB (2.2, 2.3), это как раз помещается в заказанную квоту для данного проекта.

Теперь в проекте Project 1 (accountXXXXX) у пользователя созданы две машины.

Новый проект
Прошло какое-то время и пользователь захотел создать еще одну машину размером 16 GB RAM и 120 GB диска, он подумал, что эта машина никак не относится к предыдущим двум и решил для нее создать новый проект (Project 2). В биллинге, согласно уроку 1 он заказывает для нового проекта, новую услугу Cloud2 (3). Поскольку это новый проект, то у него новая учетная запись accountXXXXY и в нем опять нет машин, а только заказаны ресурсы.

В рамках одного проекта машины имеют дополнительную приватную 10 Gbit/s сеть.

Пример: наш пользователь — компания-интегратор и для каждой своей подопечной компании выделяет отдельный проект с именем «Компания АБВ», где и создает виртуальные машины для этой компании. Он может даже выдать системному администратору компании доступ к облаку, в котором будет видно только машины этой компании.

Создав новый проект, пользователь может войти в панель Cloud2 с данными для accountXXXXY (3.1), где создает виртуальную машину VM3 (3.2) с диском 120 GB и RAM 16GB.

Расширение ресурсов проекта
Через некоторое время пользователь понял, что в проекте Project 1 необходимо создать еще одну виртуальную машину с 4 GB RAM и 20 GB диска. Однако, в проекте заказаны ресурсы 2 GB RAM и 20 GB диска и они все потрачены на VM1 и VM2. Тогда пользователь обращается в техническую поддержку (4) с заявкой о выделении дополнительных ресурсов (4). Техническая поддержка выделяет пользователю дополнительно 4 GB RAM и 20 GB дискового пространства и его проекты в биллнге теперь соответствуют тем, которые отображены на шаге (5). У пользователя теперь достаточно ресурсов в проекте Project 1 для создания требуемой машины.

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

Пользователь входит в панель управления Cloud2 под аккаунтом accountXXXXX и создает VM4 (2.1, 5.1). Теперь у него в проекте Project 1 (accountXXXXX) снова нет свободных ресурсов, пока он не удалит какие-то из машин VM1, VM2, VM4.

Удаление проекта
Через некоторое время наш пользователь понял, что проект Project 2 больше не нужен и его необходимо закрыть, а виртуальную машину VM3 удалить. В биллинге в разделе Cloud2 пользователь просто удаляет проект (6), что приводит к удалению виртуальной машины в нем.

Тарификация
В Cloud2/Premium используется посуточная тарификация на основе заказанных ресурсов. Как только вы создали проект и заказали для него ресурсы с учетной записи ежесуточно будет списываться 1/30 стоимости услуги, даже если в проекте нет виртуальных машин или используются не все заказанные ресурсы. Как только вы удалили проект или заказали через службу поддержки увеличение или уменьшение ресурсов, тарификация изменяется на следующие сутки в соответствии с новыми условиями.

Данная схема работы была выбрана для удобства бизнес-пользователей, которым выделяется фиксированный бюджет на услуги, а пересмотр бюджета осуществляется организованным образом.

Заключение
Надеемся, что данная статья была для вас полезной и теперь вы лучше понимаете как управлять услугами Cloud2. Будем рады дополнить ее, если у вас возникли дополнительные вопросы.

Продажа серверов Fujitsu и Supermicro

Добрый день, уважаемые клиенты и партнёры!
Продаём серверы в связи с расчисткой склада ЗИП


Оплата наличными, возможность оплаты банковским счётом уточнять в отделе продаж. Гарантия месяц.
По вопросам приобретения обращаться в отдел продаж:
09:00–17:00 Пн.–Пт.: +7(3822)705-476, nov@netpoint-dc.com

Новый розыгрыш — 2 комплекта Xbox One X

Первый поощрительный розыгрыш в поддержку Cloud2 успешно завершился и приз нашел своего владельца. Мы решили, что это не предел и запланировали еще один розыгрыш еще большего масштаба. В рамках этой акции мы планируем подарить 2 комплекта Xbox One X — самой прогрессивной консоли для игр и медиаконтента.



Стать участником нового розыгрыша очень просто:
  • закажите аккаунт в Cloud2 с объемом заказанных ресурсов не менее 4 GB RAM, 60 GB дискового пространства (1100 рублей в месяц);
  • перенесите в аккаунт ваш сайт или информационную систему самостоятельно или закажите бесплатный перенос силами наших специалистов. Мы выполняем перенос с хостинга, виртуальных серверов, аппаратных серверов.
  • своевременно пополняйте и оплачивайте услуги.
Хотите участвовать, но нет времени самостоятельно разбираться?

Свяжитесь с нашим специалистом по работе с клиентами Натальей:
  • С понедельника по пятницу c 9:00 до 17:00 (Москва +4 часа): +7 (3822) 705-476
  • В любое время по e-mail: nov@netpoint-dc.com
  • В розыгрыше участвуют счета, по которым расходы на услугу Cloud2 с 1 по 31 января 2019 года превысили 1100 рублей.

Определение победителей
Розыгрыш состоится 10 февраля 2019 года. Розыгрыш будет осуществляться случайным выбором из всех счетов в биллинге, которые удовлетворяют указанным выше критериям. Номера всех счетов, участвующих в розыгрыше, будут опубликованы на сайте НетПоинт.

Мы напоминаем, что Вы можете заказать бесплатный перенос вашего ресурса как с услуги CS1 так и с других услуг НетПоинт в Cloud2, а так же со сторонних площадок.

Все аккаунты, которые уже используют Cloud2 и соответствуют критериям, описанным выше участвуют в розыгрыше.

Поздравляем победителя розыгрыша!

В нашей компании завершилась акция, проходившая с 18 октября по 18 ноября 2018 года среди пользователей новой услуги Cloud2.

В результате розыгрыша, проведённого 20 ноября, победителем и владельцем NVMe SSD ускорителя нового поколения Intel Optane 900p 480GB стал Башкирцев Матвей Николаевич!

От всей души поздравляем Матвея Николаевича и желаем ему, чтобы удача и успех и дальше сопутствовали во всех его начинаниях!

Список участников и проведение розыгрыша среди пользователей Cloud2

Сегодня мы публикуем список участников розыгрыша NVMe SSD ускорителя Intel Optane 900p 480GB среди пользователей Cloud2!
В соответствии с правилами, в розыгрыше участвуют только те аккаунты, расходы по которым в период с 18 октября по 18 ноября суммарно составили от 1100 рублей.
Мы специально не публикуем ФИО участников и их email, чтобы избежать непреднамеренного распространения ваших персональных данных.
Вместо этого идентификатором участника в розыгрыше будет являться код услуги Cloud 2, который вы всегда можете посмотреть в списке своих услуг в биллинге, например:


Список кодов услуг, участвующих в розыгрыше*:
12671
12687
14003
14010
14327
14391
14398
14604
14644
14713
14754
14761
14765
14768
14842
14893
Если вы считаете, что вы попадаете под участие в розыгрыше согласно условиям акции, но вашей услуги нет в списке участников, напишите нам на support@netpoin-dc.com

Проведение розыгрыша
Розыгрыш будет проведён 20 ноября 2018 года в 11:00 по томскому времени путём случайного выбора публичным генератором randstuff числа из представленного выше списка.
Трансляция розыгрыша будет доступна на www.youtube.com/watch?v=VotiVs98-wU

Спасибо за внимание и удачи нашим участникам!

Частота CPU для виртуальных машин LowCPU увеличена в два раза



Уважаемые абоненты, в рамках продолжения цикла улучшений услуги Cloud2 мы увеличили частоту vCPU для экземпляров LowCPU в 2 раза. Теперь частота ядра составляет 2 GHz, ранее была 1 GHz. Это означает, что машины LowCPU теперь будут работать в два раза быстрее.

Для активации новой частоты необходимо остановить машину в панели и запустить ее снова.

Мы по-прежнему не рекомендуем машины LowCPU для нагруженных проектов, позиционируя их как решения для малых серверов специальных нужд — DNS, VPN, Proxy, FTP, балансировщик Nginx и т.п. Для сервисов, которым требуется высокая производительность и низкая задержка обработки выбирайте только машины HighCPU или Ultra (скоро будут доступны).

Спасибо за то, что вы выбираете наши услуги.
billing.netpoint-dc.com/billmgr?func=register&lang=ru

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



В этой статье мы разберем как устроена каждая виртуальная машина в Cloud2, что позволит вам лучше понимать как использовать возможности Cloud2 наилучшим образом. Схема машины отражена на рисунке, в статье рассмотрим назначение и рекомендации по всем компонентам VM.



Виртуальная машина состоит из следующих компонентов, которые перечислены далее:
  • Ядра vCPU — виртуальный процессор VM;
  • RAM — область оперативной памяти VM, которая выделена ей в использование;
  • контроллер Watchdog I6300ESB;
  • ROOT-диск — первый диск виртуальной машины;
  • DATA-диски — опциональные диски, которые могут быть добавлены к виртуальой машине;
  • NIC0 — управляемая сетевая карта, настройки которой выделяются по DHCP;
  • NIC1-N — дополнительные неуправляемые сетевые карты, которые не отображаются в интерефейсе панели и используются для создания дополнительных частных сетей.
Разберем все компоненты по-отдельности.

Ядра vCPU
Данный параметр определяет вычислительные возможности виртуальной машины. В зависимости от типа машины выделяются различные ядра и выполняются различные соотношения между физическими ядрами (включая Hyper-Threading) и виртуальными ядрами:
  • Lowcpu — соотношение виртуальных и физических ядер для вычислительного узла — 1:3. Таким образом, на одно физическое ядро может выделяться до 3х виртуальных, что определяет потенциально более низкую производительность CPU. Частота ядра виртуального процессора от 1.00 до 3.00 GHz. Данный тип машин не рекомендуется для задач, когда требуется гарантировать производительность операций, поскольку в определенные моменты доступная частота может значительно упасть из-за перегрузки CPU.
  • Highcpu — соотношение виртуальных и физических ядер для вычислительного узла — 1:1-1.5. На одно физическое ядро выделяется от одного до полутора виртуальных ядер. На практике можно считать, что соотношение 1 к 1. Таким образом, в случае Highcpu вы можете рассчитывать на полную производительность физических ядер, выделенную монопольно для вашей виртуальной машины. Частота ядра виртуального процессора от 2.90 до 3.80 GHz, что делает этот тип машин подходящими для сервисов, которым требуется высочайшая производительность ядер, например, для использования с приложениями, от которых ожидается стабильный отклик с минимальной задержкой.
  • Ultra — соотношение ядер 1:1. Частота ядер от 2.90 до 3.80 GHz. В этом типе машин виртуальной машины всегда доступны все ресурсы нижележащего CPU. Обычно, производительность CPU VM Ultra соответствует CPU Highcpu, однако, в крайних случаях Ultra может быть несколько быстрее.

Чтобы у вас сложилось представление о том, как в реальности утилизируются физические CPU на узлах, мы предлагаем вашему вниманию изображение чарта утилизация CPU для узла Highcpu.



Можно видеть, что процессор загружен не более чем на 22% (зеленая область представляет собой свободные ресурсы). Данный узел уже выделен на 60% по памяти. Таким образом, процессор не является узким местом. Это изображение отражает картину утилизации CPU, характерную для всех узлов Highcpu и показывает, что вы можете рассчитывать на доступность всех ядер в полном объеме.

RAM
В Cloud2 используется гипервизор KVM, каждой машине выделяется заказанный объем RAM, который монопольно используется машиной по своему усмотрению.

ROOT-диск
Первый диск виртуальной машины. Данный диск используется для размещения операционной системы. Его размер может увеличиваться пользователем при необходимости. Производительность ROOT-диска определяется характеристиками, которые заданы для сервисного предложения. Например, для машины highcpu.2c4g определены следующие характеристики доступа к ROOT-диску:
  • Read IOPS: 2000
  • Write IOPS: 1000
  • Read MBS: 160
  • Write MBS: 80
Таким образом, независимо от размере ROOT-диска виртуальная машина highcpu.2c4g будет обладать вышеуказанными характеристиками доступа к ROOT-диску. Если указанной производительности недостаточно, необходимо сменить сервисное предложение на большее, например, highcpu.4c8g:
  • Read IOPS: 4000
  • Write IOPS: 2000
  • Read MBS: 200
  • Write MBS: 100

DATA-диски
Дополнительные диски, которые могут быть присоединены к виртуальной машине, если ее тип это позволяет. В настоящее время, мы не рекомендуем присоединять к машине дополнительные DATA-диски. Они существуют для поддержки миграции с других облаков. В том случае, если вам необходимо выполнить увеличение дискового пространства, просто выполните увеличение размера ROOT-диска.

NIC0
Первая сетевая карта управляется системой CloudStack. Данная сетевая карта автоматически получает сетевые настройки по DHCP. Так же, для данной сетевой карты Cloud2 поддерживает группы безопасности, которые используются в качестве внешнего шлюза безопасности виртуальной машины и позволяют ограничить нежелательный трафик.

NIC1
Вторая сетевая карта связывает все машины одного аккаунта в приватную сеть на скорости 10Gbit/s, что позволяет реализовать самые требовательные к скорости передачи данных задачи. Данная сеть является неуправляемой и настраивается пользователем по своему усмотрению.

NIC2 и иные
Данные сетевые карты обычно отсутствуют у виртуальной машины, но могут быть, если выполнены соответствующие настройки для учетной записи. Используются для организации дополнительных приватных сетей.

Контроллер I6300ESB
Виртуализированный «аппаратный» контроллер Watchdog, который используется для обнаружения критических состояний виртуальной машины и ее аварийного перезапуска в автоматическом режиме.

billing.netpoint-dc.com

Обновление виртуальных машин Lowcpu, Highcpu



Уважаемые пользователи, для машин LowCPU, HighCPU произведены улучшения, которые значительно увеличили производительность дискового доступа. В ходе улучшения скорость доступа на чтение в IOPS и MBs была увеличена в два раза.

Для применения изменений достаточно остановить и снова включить виртуальную машину.

Новая возможность Cloud2. Watchdog для виртуальной машины

Использование watchdog I6300ESB в виртуальных машинах в Cloud2
Сегодня мы расскажем о полезной возможности Cloud2, которая позволяет повысить доступность виртуальных машин за счет использования виртуального устройства watchdog, которое доступно внутри VPS.

Сначала несколько слов о том, что такое watchdog. В апаратных серверах промышленного класса всегда есть специальная микросхема, которая работает автономно от всего и представляет собой обычный таймер с действием при достижении нуля. По умолчанию, таймер отключен и действие не установлено, но с помощью специального программного обеспечения, например, ipmitool, можно это изменить и задать определенное поведение — например, перезапуск сервера через reset при достижении нулевого значения, а начальное значение, например, установить в 360 секунд. Далее, в системе запускается специальная программа, которая просто обновляет таймер, не давая ему достигнуть нулевой отметки. Таким образом, пока система работает и процессы выполняются, таймер обновляется и watchdog не срабатывает, однако, как только операционная система зависла, программа, обновляющая таймер перестает работать тоже. В течение максимум 360 секунд счетчик достигнет нулевой отметки, и система перезагрузится с помощью виртуального нажатия на кнопку «reset». Механизм абсолютно надежный, поскольку работает на уровне аппаратного обеспечения, позволяя администраторам в большинстве случаев значительно уменьшить время недоступности систем при возникновении ошибочных ситуаций.

Реализация для виртуальных машин. Для виртуальных машин тоже существуют реализации watchdog, которые внутри виртуальной машины воспринимаются как аппаратные, при этом виртуализация этой микросхемы производится самим гипервизором и работает отдельно от виртуальной машины. Таким образом, если виртуальная машина зависнет, гипервизор сможет выполнить заданное действие для нее, если watchdog настроен и запущен.

Реализация в Cloud2. В Cloud2 используется гипервизор KVM, который поддерживает watchdog на базе микросхемы Intel i6300esb, эмуляция которой и осуществляется гипервизором. Мы задали действие для watchdog как reset, таким образом при зависании машина будет перезапускаться.

Использование watchdog в Cloud2. Использование i6300ESB в ОС Linux не представляет труда. Для начала использования необходимо выполнить следующие действия (Ubuntu Linux 16.04):

Установить ПО watchdog:
# apt-get update && apt install watchdog

Узнать как собрана поддержка устройства I6300ESB для вашей ОС:
# grep I6300ESB /boot/config-$(uname -r)
CONFIG_I6300ESB_WDT=m

Если «m», значит, модуль необходимо загрузить. Если «y», значит, что поддержка встроена в ядро, если «n», требуется пересборка ядра. Скорее всего, у вас будет «m», если это так, необходимо установить дополнительные компоненты ядра:
# apt install linux-image-extra-$(uname -r)

Теперь можно загрузить модуль:
# modprobe i6300esb
# lsmod | grep i6300esb
i6300esb 16384 1

Видим, что все отлично — модуль загружен. Теперь необходимо добавить его для автоматической загрузки. Пакет watchdog в Ubuntu позволяет сделать это через добавление параметра в настройки запуска сервиса watchdog:
# cat /etc/default/watchdog 
run_watchdog=1
run_wd_keepalive=1
watchdog_module="i6300esb"

Последняя строка как раз указывает, что надо сделать такую загрузку. Теперь выполним настройку сервиса watchdog. В самом простом варианте необходимо раскомментировать строку
watchdog-device = /dev/watchdog

в файле /etc/watchdog.conf.

Выполним запуск сервиса watchdog:
# service watchdog start

Если запуск прошел успешно, то в журнале /var/log/syslog, Вы увидите следующие записи:
Oct 2 03:55:08 sop watchdog[22526]: test=none(0) repair=none(0) alive=/dev/watchdog heartbeat=none to=root no_act=no force=no
Oct 2 03:55:08 sop watchdog[22526]: watchdog now set to 60 seconds
Oct 2 03:55:08 sop watchdog[22526]: hardware watchdog identity: i6300ESB timer

Если система зависнет, то в течение 60 секунд для нее будет выполнено действие «reset». Убедитесь, что сервис watchdog корректно стартует после перезапуска системы.

Проверить работоспособность можно посредством генерации состояния Kernel Panic:
echo c > /proc/sysrq-trigger

Не более чем через 60 секунд система должна перезагрузиться.

В статье приведена настройка только для Ubuntu Linux. Для Debian, CentOS и других ОС семейства Linux настройка будет похожа. Настройка для других операционных систем (MS Windows, *BSD и других) осуществляется посредством интерфейсов и приложений, которые в них предоставляются для взаимодействия с таймером i6300esb и в этой статье не рассматриваются.

Case Study об использовании подсистемы Linux FS-Cache

Case Study об использовании подсистемы Linux FS-Cache для решения проблемы производительности хранилища


У одного из наших клиентов большой портал, данные которого хранятся на отдельном выделенном NFS сервере. На сегодняшний день — это множество изображений, которые хранятся в одном плоском каталоге и занимают более 3 TB. Даже листинг этого каталога занимает несколько десятков секунд. До недавнего времени все работало более-менее неплохо, но потом движок обновили и случилось чудо, нагрузка на хранилище выросла на порядок. Все наши увещевания, что было хорошо, стало плохо ни к чему не привели, разработчики просто разводят руками.

Одна из самых больших проблем — это плоская структура каталога, в котором хранятся все файлы, таким образом, операции, которым нужен листинг просто превращают хранилище в тыкву и 4x2TB RAID10 никак не справляются. На периоды пиковой нагрузки мы переносили данные клиенты на наше SSD-хранилище, чтобы преодолеть проблему.

Новый виток боли начался недавно — у клиента стало заканчиваться место в хранилище, мы выполнили перенос на временный сервер, но проблема усугубилась — после перемонтирования хранилища NFS IOPS-ы стали зашкаливать, так как сервер приложений выкачивал все данные непосредственно с хранилища, и система просто встала колом. К счастью, на сервере приложений было около 500 GB высокоскоростного пространства на SSD и мы решили попробовать использовать FS-Cache для решения проблемы. Это был первый опыт применения данной технологии, но делать было нечего, все равно ничего не работало.

Проверяем совместимость ядра
# grep CONFIG_NFS_FSCACHE /boot/config-3.13.0-147-generic
CONFIG_NFS_FSCACHE=y

Отлично, ядро пересобирать не надо.

Монтируем NFS с нужным параметром FSC
server://files /mnt/vgslow-data nfs nfsvers=4,async,rw,_netdev,fsc 0 0
Обращаем внимание. Перемонтирование через remount не даст эффекта. Необходимо отмонтировать и смонтировать с параметром «fsc».

Устанавливаем и настраиваем демон кэширования
apt-get install cachefilesd
Редактируем настройки
# cat /etc/cachefilesd.conf 
###############################################################################
#
# Copyright © 2006,2010 Red Hat, Inc. All Rights Reserved.
# Written by David Howells (dhowells@redhat.com)
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version
# 2 of the License, or (at your option) any later version.
#
###############################################################################

dir /var/cache/fscache
tag mycache
brun 10%
bcull 7%
bstop 3%
frun 10%
fcull 7%
fstop 3%

# Assuming you're using SELinux with the default security policy included in
# this package
# secctx system_u:system_r:cachefiles_kernel_t:s0

В настройках мы изменили только параметр dir. Остальные параметры оставлены по умолчанию. Демон умеет определять доступное место на диске и держать его на заданных уровнях.

Указываем, что демон должен запускаться:
# cat /etc/default/cac
cacerts cachefilesd 
root@np0121:~# cat /etc/default/cachefilesd 
# Defaults for cachefilesd initscript
# sourced by /etc/init.d/cachefilesd

# You must uncomment the run=yes line below for cachefilesd to start.
# Before doing so, please read /usr/share/doc/cachefilesd/howto.txt.gz as
# extended user attributes need to be enabled on the cache filesystem.
RUN=yes

# Additional options that are passed to the Daemon.
DAEMON_OPTS=""

Запускаем сервис
service cachefilesd start

Проверяем работоспособность
# cat /proc/fs/nfsfs/volumes
NV SERVER   PORT DEV  FSID             FSC
v4 b078194a 801  0:35 16f9381700e59eda yes


Важно, чтобы в колонке FSC было yes. Это означает, что кэширование активировалось.

Теперь смотрим статистику кэша:
# cat /proc/fs/fscache/stats
FS-Cache statistics
Cookies: idx=6 dat=1890275 spc=0
Objects: alc=1097490 nal=0 avl=1097490 ded=1016804
ChkAux : non=0 ok=171729 upd=0 obs=0
Pages : mrk=148687337 unc=145492607
Acquire: n=1890281 nul=0 noc=0 ok=1890281 nbf=0 oom=0
Lookups: n=1097490 neg=925761 pos=171729 crt=925761 tmo=0
Invals : n=0 run=0
Updates: n=0 nul=0 run=0
Relinqs: n=1759445 nul=0 wcr=0 rtr=0
AttrChg: n=0 ok=0 nbf=0 oom=0 run=0
Allocs : n=0 ok=0 wt=0 nbf=0 int=0
Allocs : ops=0 owt=0 abt=0
Retrvls: n=2393196 ok=465345 wt=723800 nod=1927851 nbf=0 int=0 oom=0
Retrvls: ops=2393196 owt=662915 abt=0
Stores : n=118288880 ok=118288880 agn=0 nbf=0 oom=0
Stores : ops=2049040 run=120337487 pgs=118288447 rxd=118288880 olm=0
VmScan : nos=145461870 gon=0 bsy=0 can=433 wt=11
Ops : pend=662994 run=4442236 enq=153450538 can=0 rej=0
Ops : dfr=36586 rel=4442236 gc=36586
CacheOp: alo=0 luo=0 luc=0 gro=0
CacheOp: inv=0 upo=0 dro=0 pto=0 atc=0 syn=0
CacheOp: rap=0 ras=0 alp=0 als=0 wrp=0 ucp=0 dsp=0

Если счетчики двигаются, значит все ОК, настройка завершена.

Заключение
Нам повезло, что нагрузка клиента в основном представляет собой операции чтения, что позволяет использовать FS-Cache совместно с NFS. Если бы проблема была в нагрузке по записи, мы бы не смогли эффективно воспользоваться данной технологией.

billing.netpoint-dc.com/billmgr?func=register&lang=ru