1. Трохи про проект
2. Установка та базове налаштування Varnish
3. просунуті налаштування
4. управління Varnish
5. висновок

Обробка великої кількості запитів може бути вельми важким завданням забирає ресурси веб-сервера. Щоб зняти навантаження використовують фронтенд в якості якого може виступати легкі nginx / lighttpd або кешуючий проксі-сервер. У другому якості дуже популярний Squid, він універсальний, але не завжди є оптимальним. Але саме в цьому завданні його більш ефективно замінює Varnish.

Трохи про проект

Varnish (varnish-cache.org) являє собою кешируєтся "зворотний" (reverse) проксі-сервер і акселератор HTTP. Принцип його роботи взагалі стандартний для такого класу програм. Він отримує запит, обробляє його і відразу видає відповідь якщо він присутній в кеші, якщо немає то звертається до веб-сервера за результатом. Відповідь міститься в кеш. Varnish написаний з нуля для норвезької газети Верден Gang. Версія 1.0 з'явилася в 2006 році, в 2014 представлений реліз 4.0. Основний код доступний під BSD-подібної ліцензії, але є і комерційні модулі.
З'явившись проект відразу привернув себе увагу досить гучними заявами свого автора і одного з розробників FreeBSD Пол-Хеннінга Кампа (Poul-Henning Kamp), про те що все, що є (з натяком на Squid) зроблено не правильно. І дійсно Varnish виділяє сучасний дизайн ефективно використовує можливості сучасних багатопроцесорних систем (Sqiud навчився працювати з SMP трохи пізніше з версії 3.2). Нить реалізована за допомогою стандартних потоків POSIX, їх кількість регулюється. Це одна з причин чому Varnish не дуже добре працює в Windows. Кожен запит обробляється в окремому потоці. Причому з версії 4.0 за отримання запиту від користувача і передача запиту серверу відповідають різні потоки, що ще більш підвищило продуктивність. Varnish підтримує технологію ESI (Edge Side Includes) дозволяє розбивати веб-сторінку на частини і запитувати їх окремо. Кеш може зберігати будь-яку інформацію. В результаті Varnish відмінно підходить для кешування дінмаміческого контенту.
Для зберігання даних (кешу, журналів операцій) використовується віртуальна пам'ять, управлінням того що вивантажується на диск займається ОС. Тут автори Varnish справедливо вважають, що розробники ОС свою справу знають, а дублювання тільки погіршує продуктивність.
На відміну від Squid який спочатку більше орієнтувався на кешування клієнтських запитів, Varnish був розроблений і оптимізований саме в якості прискорювача HTTP і нічого іншого більше не вміє. Ми не знайдемо тут підтримку інших протоколів (FTP, SMTP та інші), не побачимо можливості прямого проксі - кешування веб-сторінок для економії зовнішнього трафіку (Varnish «прив'язується» до бекенда). Природно відрізняється і можливості по конфігурації.
Мова конфігурації Varnish Configuration Language (VCL) - динамічний, скрипт сам по собі по суті є окремим плагіном. Код транслюється в С (можна відразу писати вбудовується код на С), після чого інструкції компілюються в бібліотеку і завантажуються в пам'ять. Можна вносити зміни в конфігурацію «на льоту». Інструкції в VCL дозволяють: кешувати лише певні запити, знижуючи навантаження при генерації динамічних об'єктів, блокувати доступ до певних каталогів і скриптів, підміняти заголовки і багато іншого. Є і механізм перевірки працездатності бекенд (завмер часу відповіді, лічильник невдалих перевірок і т.д.), можливість перезапису і перенаправлення (rewrite) запитів. Взагалі такий підхід дозволяє виробляти з HTTP трафіком практично будь-які маніпуляції, які можна обмежити лише власною уявою. Підтримується балансування навантаження кілька алгоритмів (round robin, random і DNS, Client IP). Можливості розширюються за допомогою модулів, званих VMOD (Varnish MODules). Проект надає необхідну документацію дозволяють написати такий модуль самостійно. Частина модулів (varnish-cache.org/vmods) вже включені в стандартне постачання, деякі доступні у вигляді концепту або знаходяться в розробці.

Проект вже надає велику кількість модулів

Сьогодні Varnish використовують такі веб-сервіси як Facebook, Twitter, Vimeo і Tumblr.

Установка та базове налаштування Varnish

Офіційно рекомендується установка Varnish на сучасних версіях x64 бітних Linux, FreeBSD або Solaris. Пакети можна знайти в додаткових репозитариях (на кшталт EPEL або Ubuntu Universe) більшості дистрибутивів Linux і портах * BSD систем. Сам проект надає репозитарії і докладні інструкції для Red Hat, Debian, Ubuntu і FreeBSD. У більшості випадків слід використовувати саме репозитарій розробника, так як в ньому знаходиться свіжіша версія продукту. Можлива робота і в Windows (через Cygwin), але оптимізація під * nix системи не гарантують максимальну продуктивність результату. На сайті доступні дві версії Varnish 3.x і 4.x, обидві є стабільними, але підтримка лінійки 3.x буде припинена в першій половині 2015 року. До речі код досить добре написаний, тому виправлень вноситься мало (наприклад 3 гілка з'явилася в червні 2011 містила всього 6 версій) можна не бояться використовувати новинки. Стандартно Varnish ставиться перед веб-сервером кешіруя запити. У навантажених системах іноді використовують більш складний варіант, коли спочатку запит приймає легкий веб-сервер (nginx, lighttpd), який вміє швидко віддавати певні сторінки. При необхідності цей сервер, через Varnish звертається до основного HTTP-сервера генерує контент. Varnish при наявності інформації в кеші віддає її звідти.
Для прикладу встановимо Varnish в Ubuntu 14.04 LTS як фронтендів Apache. В інших дистрибутивах відмінності тільки в розташуванні конфігураційних файлів і особливості пакетних систем.

$ Sudo apt-get install apt-transport-https curl $ sudo curl https://repo.varnish-cache.org/ubuntu/GPG-key.txt | apt-key add - $ sudo echo "deb https://repo.varnish-cache.org/ubuntu/ trusty varnish-4.0" >> /etc/apt/sources.list.d/varnish-cache.list $ sudo apt -get update $ sudo apt-get install varnish

Ось власне і все. Після установки Varnish стартує і щось там кешируєт. Займемося конфигурированием.
Установки параметрів запуску демона проводиться в файлі / etc / default / varnish. Спочатку він налаштований з деякими параметрами. Якщо відкрити файл, то побачимо всередині три готові настройки: minimal, c VCL і advanced.

Файл / etc / default / varnish

За замовчуванням активований другий режим. При цьому сервер приймає підключення на порт 6081, для адміністрування використовується localhost: 6082, а бекенда визначаються в VCL. Для кешування виділяється 256 Мб пам'яті. Налаштуємо так щоб Varnish слухав 80 порт, кешіруя запити HTTP сервера розташованого на цій же машині. Коментуємо настройки 2 варіанти і як шаблон будемо використовувати Advanced, як більш наочний.

$ Sudo nano / etc / default / varnish # Запускати демон varnishd при завантаженні системи. START = yes # Максимальна кількість відкритих файлів (для ulimit -n) NFILES = 131072 # Максимальна кількість залоченним пам'яті (for ulimit -l) для блокування пам'яті, що балки # при необхідності слід збільшити розмір MEMLOCK = 86000 # За замовчуванням екземпляр сервера отримує ім'я поточного вузла. При запуску декількох екземплярів його можна перевизначити за допомогою -n або # INSTANCE = $ (uname -n) # за умовчанням слухаються всі інтерфейси, але можемо вказати IP # VARNISH_LISTEN_ADDRESS = # порт на якому приймаються підключення VARNISH_LISTEN_PORT = 80 # Адмін інтерфейс IP і порт VARNISH_ADMIN_LISTEN_ADDRESS = 127.0.0.1 VARNISH_ADMIN_LISTEN_PORT = 6082 # VCL файл VARNISH_VCL_CONF = / etc / varnish / default.vcl DAEMON_OPTS = "\ -a $ {VARNISH_LISTEN_ADDRESS}: $ {VARNISH_LISTEN_PORT} \ -f $ {VARNISH_VCL_CONF} \ -T $ {VARNISH_ADMIN_LISTEN_ADDRESS} : $ {VARNISH_ADMIN_LISTEN_PORT} \

Це основні установки. З рештою можна познайомитися в файлі або в документації проекту.
Розбудовуємо Apache, щоб він слухав 8080 порт. Залежно від поточних установок це можна зробити в різних файлах, в загальному ідея виглядає так:

$ Sudo nano /etc/apache2/ports.conf NameVirtualHost *: 8080 Listen 8080

Тепер залишилося вказати Varnish, де знаходиться HTTP-сервер. В / etc / default / varnish це можна зробити за допомогою ключа -b (-b localhost: 8080), але зручніше для цього використовувати VCL файл, який вказаний у змінній VARNISH_VCL_CONF (в сирцю є приклад example.vcl). Відкриваємо і дивимося, щоб усередині була інструкція:

$ Sudo nano /etc/varnish/default.vcl backend apache {.host = "127.0.0.1"; .port = "8080"; }

Мінімальні установки готові. Перезапускаємо Varnish:

$ Sudo service varnish start

Перевіряємо за допомогою netstat слухається чи порт і доступний веб-сервер.

просунуті налаштування

Це найпростіший приклад і як бачимо змусити Varnish кешувати запити дуже легко, але він поки не «розбирається» і не втручається в трафік. Познайомившись з VCL можна розширити базові можливості. Параметрів які можна налаштувати дуже багато і щоб їх описати потрібно книга. VCL це мова програмування в якому знайдемо все що притаманне - змінні, функції, коментарі і т.п. Варіантів використання багато і відразу їх освоїти не вийде. У якості відправної точки можна рекомендувати документацію проекту, зокрема Varnish Book (varnish-software.com/static/book). Також в Мережі вже є досить шаблонів (github.com/mattiasgeniar/varnish-3.0-configuration-templates) під різні ситуації підготовлених самими користувачами. Вони є гарною підмогою з вивчення можливостей VCL.
Varnish здатний працювати з декількома HTTP-серверами (бекенд). Кожен визначається аналогічно прикладу вище:

backend server1 {.host = "10.0.0.11"; } Backend server2 {.host = "10.0.0.12"; }

Після чого можна будувати правила вказуючи сервера на ім'я.
Якщо бекенд рівнозначні і використовуються тільки для розподілу навантаження, то досить повідомити про це Varnish за допомогою директиви "director":

director balanced_servers round-robin {{.backend = server1; } {.Backend = server2; }}

Можна також використовувати випадковий вибір - для цього замість "round-robin" необхідно прописуємо "random".
Можлива реалізація і більш складних алгоритмів. Але для цього треба бути обізнаним з можливостями VCL файлів.
У default.vcl ми побачимо кілька іменованих блоків (функцій). За умовчанням параметри всередині відсутні, ось саме з їх допомогою і проводиться тонка настройка кешування. Дещо можна встановити не вникаючи в роботу додатків на веб-сервері, в більш складних випадках потрібно глибокий аналіз видаються сторінок (проект надає деякі утиліти про які далі).
Розберемо деякі з них. Порядок виклику функцій наочно показаний в розділі [VCL Basics] (varnish-software.com/static/book/VCL_Basics.html), деякі питання конфігурації є в [документації] (varnish-cache.org/docs).
Списки ACL дозволяють упралявть доступом до певних URL або вручну розподіляти або обробляти запити деяких клієнтів. Створимо правило яке включає всі локальні вузли.

acl local { "localhost"; "192.168.1.0" / 24; ! "192.168.1.10"; }

Як бачимо дозволяється інвертування за допомогою «!» Тобто 192.168.1.10 не підпадає під правило. Тепер до цього списку можемо звернутися за допомогою конструкції (client.ip ~ local)
Функція vcl_recv викликається при отриманні запиту і перед перевіркою даних в кеші. Саме тут можна модифікувати запит, видалити Cookie, зробити нормалізацію, вибрати бекенда в залежності від запиту і т.д.
За замовчуванням Varnish НЕ кешируєт запити з встановлено Cookie. Для статичних сторінок, краще активувати таку можливість, для цього просто вирізаємо Cookie. Також для прикладу заборонимо доступ до файлів cron.php і install.php для всіх вузлів крім локальних і скажемо Varnish, щоб він перенаправляв всі запити до update.php відразу на бекенда.

sub vcl_recv {set req.backend = apache if (req.url ~ "\. (css | js | png | gif | jp (e)? g)") {unset req.http.cookie; } Return (lookup); if (req.url ~ "^ / (cron | install) \. php $" &&! client.ip ~ local) {error 404 "Page not found."; } If (req.url ~ "^ / update \ .php $" return (pass);}}

Це звичайно не все, що можна зробити. Використовуючи req.http.User-Agent можемо розподіляти бекенд в залежності від браузера / пристрої клієнта. Детальніше (varnish-cache.org/docs/trunk/users-guide/devicedetection.html).
Функція return у випадку з vcl_recv може приймати аргументи: lookup - вказує на необхідність пошуку в кеші, pass - відразу відправляє запит на бекенда. Останнє як бачимо дозволяє уникнути кешування певних типів файлів, наприклад медіа або постійно оновлюваного контенту.
Деякі функції викликають порожніми, просто щоб пропустити певну перевірку вказавши потрібний код возрата. Крім зазначених вище можливі варіанти - deliver, fetch, hash, pipe, error, restart, retry.
Функція vcl_hash дозволяє визначити унікальність запиту, який буде кешуватися. За замовчуванням хеш формується на підставі URL і IP / імені сервера. У більшості випадків цього достатньо, але в деяких ситуаціях цього бракує і можливо буде потрібно зміна правил. Наприклад, для визначення унікальності використовують Сookie.
Функція vcl_error дозволяє генерувати контент не звертаючись до веб-сервера, використовується для видачі повідомлень про помилки і редиректу.
Далі в залежності від ситуації запит обробляється vcl_fetch, vcl_pass і vcl_miss. В 4.0 вони замінені більш зручні функції vcl_backend_fetch і vcl_backend_response, які викликаються перед передачею запиту серверу і після отримання відповіді, відповідно.
У наступному прикладі ми прибираємо виставлення cookie для файлів зображень, а також задаємо час життя кешованого вмісту для цих файлів в 1 годину.

sub vcl_backend_response {if (bereq.url ~ "\. (png | gif | jpg) $") {unset beresp.http.set-cookie; set beresp.ttl = 1h; }}

І перед відправкою отриманих від бекенда даних викликається функція vcl_deliver. У найпростішому випадку вона пустує, тобто відповідь передається без змін. Але тут можна при бажанні модифікувати заголовки. Для прикладу просто видалимо всі згадки про Varnish:

sub vcl_deliver {remove resp.http.X-Varnish; remove resp.http.X-Powered-By; }

Це звичайно далеко не всі можливості, але потрібно йти далі.

управління Varnish

Роботою Varnish можна управляти і відстежувати результат. Для цього в постачанні йде кілька утиліт починаються з varnish *. Всі вони описані в розділі «Appendix A: Varnish Programs» Varnish Book. Основний утилітою є varnishadm. Саме з її допомогою проводиться адміністрування, перегляд статусу і помилок, завантаження модулів «на льоту». Принцип роботи дуже простий. викликаємо:

$ Sudo varnishadm

Після чого з'явиться запрошення Varnish CLI. Щоб отримати список команд слід ввести «help».

Список команд varnishadm

Команд не багато (23), значення більшості зрозуміло з назви. Подробиці по кожній можна отримати ввівши «help команда«. Наприклад, група команд vcl. * Дозволяють переглядати і управляти завантаженням, вивантаженням модулів. Дивимося список модулів:

varnish> vcl.list

Команди param.show і param.set дозволяють переглядати і змінювати параметри сервісу, panic.show і panic.clear - відображати і очищати помилки, ban і ban.list - вказувати сторінки не підлягають кешуванню. І так далі.
Дві команди varnishtop і varnishhist дуже допомагають при початкового налаштування тому дозволяють переглянути список найбільш приватно зустрічаються параметрів (URL, ідентифікатори, статус і т.д.). Перша утиліта виводить їх у вигляді top, друга як гіксограму. При запиті можна використовувати регулярні вирази, тому загубитися у великій кількості сторінок неможливо. Наприклад, переглянемо список найбільш запитуваних URL і заголовки:

$ Varnishtop -i RxUrl $ varnishtop -i RxHeader

Ще три дуже корисних утиліти дозволяють переглянути статистику (varnishstat), і інформацію в журналах (varnishlog і varnishncsa). Скрипт varnishtest дає можливість перевірити роботу кеша Varnish.
Для тих хто не хоче розбиратися з командним рядком розробник пропонують веб-інтерфейс Varnish Administration Console (varnish-software.com/resources/vac-demo) - дуже зручний інструмент пропонує провести всі описані операції і отримувати статистику в наочному вигляді.

Інтерфейс Varnish Administration Console

Правда є мінус - доступний він тільки в комерційній версії Varnish Plus.
Безкоштовне ПЗ поки не багато варіантами. Модулі підтримують Varnish є в системах моніторингу Collectd, Nagios, Cacti та інших. Список відомих проектів можна знайти на сайті (varnish-cache.org/utilities).

! [Caption id = "attachment_3853" align = "alignleft" width = "620"] Графік завантаження Varnish в Collectd [/ caption] (6.jpg)

висновок

Varnish це дуже гнучка програма, що дозволяє управляти кешуванням трафіку з веб-ресурсів. Великі можливості мають на увазі велику кількість налаштувань. Тому деякий час доведеться затратити на їх вивчення і підгонку під конкретні умови. Але результат того вартий.