понедельник, 19 ноября 2012 г.

Squid: Как не допустить превращения прокси в публичный


Дело в следующем. Катастрофическое снижение входной планки в IT приводит к тому, что ламаки заполонили все доступное пространство и не знают даже таких очевидных вещей.

Побуду и я Капитаном Очевидность. :) Как говорится, покапитаню. :)

 Задача ограничения доступа извне к локальному сквиду средствами сквида 2 не решается, к сожалению. Дело в том, что прозрачный прокси (в особенности в отсутствие аутентификации) в простых инфраструктурах действительно доступен извне при малейших огрехах в конфигурации роутера.

Итак, проблема в том, что Squid 2 слушает адрес 0.0.0.0 и в большинстве случаев его собственными средствами ограничить доступ к порту 3128 не получится.

Что ж, мы в любом случае имеем дело с транспарентным прокси и у нас в распоряжении имеется файрвол (Solaris 10, Ipfilter). 

Сделаем это:

root @ ktulhu / # cat /etc/ipf/ipnat.conf 
rdr bge0 0.0.0.0/0 port 80 -> 0/32 port 3128 

root @ ktulhu / # cat /etc/ipf/ipf.conf
# Transparent proxy host 
# Host with one interface: 
# bge0 - internal (ktulhu) 
# Rules by Y.Voinov (C) 2007,2012 

# Block rules for RPC (open firewall) 

block return-rst in quick from any to any port=111 
block return-rst in quick from any to any port=6112 

# Restrict access to proxy only from localnet 
pass in quick proto tcp from 192.168.0.0/16 to ktulhu port=3128 flags S keep state keep frag 
# Restrict access to local Apache ports from LAN only 
pass in quick proto tcp from 192.168.0.0/16 to ktulhu port=8080 flags S keep state keep frag 
pass in quick proto tcp from 192.168.0.0/16 to ktulhu port=8088 flags S keep state keep frag

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

Вот и все. Конфигурация проста и эффективна. Сервисы со стороны открытых портов не запущены либо минимизированы.

пятница, 16 ноября 2012 г.

Бардак автоматизировать нельзя

... потому что получается автоматизированный бардак.

Не знаю, как вы - а меня дико забавляют биллборды "Бегай по клавиатуре, а не по кабинетам".

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

Хорошо известной профессионалам от IT фразе, вынесенной в заголовок, на моей памяти лет этак 20 как исполнилось. И за это время ничего не изменилось.

Вы знаете, мальчики и девочки, слово "автоматизация" не является синонимом к слову "оптимизация". Никогда.

Судите сами.

Во-первых, для беготни по клавиатуре вам-таки придется оторвать задницу от кресла, и с документом, удостоверяющим личность, стаскать свою задницу за получением ЭЦП. Заплатив за это, разумеется, энную сумму.

Причем для вас будет страшным сюрпризом, что у ЭЦП, оказывается, есть срок годности и этот срок годности совсем не велик - всего-то от годика до трех. Т.е. вам придется регулярно заниматься профилактикой геморроя.

Во-вторых, наши удостоверяющие центры, кроме того, что они являются дебилоидами и, вместо тупого следования мировому стандарту (коей называется X.509v3) изобрели свою собственную плохо совместимую поделку на основе криптографии ГОСТ, еще и могут в любой момент тупо отозвать CA - что вообще является нонсенсом - и инвалидировать разом все дерево подписанных им ЭЦП. Что уже имело место быть в нашей практике.

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

Но это все еще семечки.

Отдельная голубая печаль - сами бюрократические процессы, которые подобным образом пытаются облегчить.

Ситуация лично мне глубоко непонятна. Вместо того, чтобы сейчас, да-да, в XXI веке, тупо УПРАЗДНИТЬ многие архаизмы, бюрократизмы и кретинизмы времен развитого социализма - благо, автоматизация это вполне позволяет технически, вы же, болваны, нас всех заставили получить ИНН! - эти самые бюрократизмы просто автоматизировали (причем еще и не лучшим и непрофессиональным образом).

Скажите мне, глупому - кому нужна в XXI веке прописка? Кому нужна регистрация по месту жительства? Разве Столыпин не отменил крепостное право сто с лишним лет назад?

Характерный пример - ЦОНы. Да, вы собрали в одном флаконе большинство бюрократических процедур. И даже где-то что-то автоматизировали. Однако сами низовые процедуры и процессы ТАК И ОСТАЛИСЬ НЕИЗМЕННЫМИ.

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

Ну и какой в этом практический смысл?

Я вижу (теоретически и утопически) eGovernment как систему, имеющую в основе МИНИМУМ бюрократии, и, к тому же, позволяющую мне В ПРИНЦИПЕ ИЗБЕЖАТЬ ЛЮБОГО ЛИЧНОГО ОБЩЕНИЯ с ненавистными мне государственными структурами на всю мою жизнь. Исключая два случая, когда я лично не могу взаимодействовать с ними - при рождении и при смерти. И ВСЕ!

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

И мы как-бы верим.

PS. А все сделанные попытки сильно напоминают те самые попытки автоматизировать бардак, и, мало того, весьма смахивают на очень сомнительные подачки с барского плеча, которые непонятно для кого и зачем делаются. Вот как примерно сейчас в России - да, мы отменяем доверенности на управление автомобилем - якобы отменяем! - но для самых ключевых моментов она ВСЕ РАВНО НУЖНА. Шаг вперед - три шага назад. XXI век. Нет, ребята. "Отменяем" - это означает - раз! - и больше нигде и никогда не требуется и не применяется! Электронное правительство - это значит - раз! - и я больше никогда не узнаю, как выглядит государственный чиновник! Смекаете?

четверг, 15 ноября 2012 г.

Блокируем Хамачи

UPDATED
Когда имеете дело с продвинутыми пользователями, то и дело норовящими попробовать ваш контроль доступа на прочность, не следует забывать о Хамачи. Почему-то продвинутые порнографынекоторые пользователи считают, что они умнее системных и сетевых администраторов. Что ж, самое время их в этом разубедить.

Маленькое лирическое отступление. Я бы, возможно, даже не вспомнил о Хамачи, если бы мне не напомнил один мой закоренелый пользователь. В его логах сверкнула скачка клиента Хамачи. Ну и привлекла внимание, разумеется. Так как он не раз уже попадался на CPзапрещенном в нашем шалмане контенте, он, разумеется, просматривается чаще остальных.

Что ж, он сам напросился. Небольшое исследование вопроса привело к тому, что можно перекрыть адресный диапазон Хамачи средствами роутера, а также закрыть основные сервера сервиса. Разумеется, можно было бы средствами прокси просто по регулярному выражению запереть все урлы, содержащие ключевое слово, однако это недостаточно эффективно и, главное, бесполезно, когда клиент уже проскочил в сеть (разумеется, его можно и на флешке притащить, следовательно блокировать надо на уровне доступа к сервису, как Tor).

Ничего, что мы сетку /8 блокируем? ;) Don't panic. Ничего существенного не задавим.

Итак, вперед (на циске):


ip access-list extended NAT
 deny ip 192.168.0.0 0.0.255.255 host 64.34.106.33 
 deny ip 192.168.0.0 0.0.255.255 host 64.34.106.7 
 deny ip 192.168.0.0 0.0.255.255 host 69.25.21.195 
 deny ip 192.168.0.0 0.0.255.255 host 74.201.75.195 
 permit ip 192.168.0.0 0.0.255.255 any ip 

access-list extended WAN_IN 
 deny ip 25.0.0.0 0.255.255.255 any 
 deny tcp any any eq telnet
 deny tcp any any eq smtp
 deny tcp any any eq domain
 deny tcp any any eq www
 deny tcp any any eq 443
 permit ip any any
!

Да, можно было, конечно, накидать тривиальных access list, но, поскольку в нашей инфраструктуре используется двойной NAT, так изящней.

В качестве просто подстраховки, дабы неповадно было, добавим acl в прокси от отрежем всякие упоминания о сабже от слишком продвинутых:

# Hamachi 
acl hamachi urlpath_regex -i Hamachi

...

# Deny access to Hamachi 
http_access deny hamachi
 
Вот и все. Спи спокойно, дорогой друг. Всех серверов Хамачи это не закроет, однако большинство точек входа перекрыты.

PS. Если кому-то взбрендится задать вопрос, как согласуются мои действия с тем черным значком вверху справа, могу заметить, что свобода интернета не предполагает игнорирования корпоративных правил и, вообще говоря, начинается за порогом вашей квартиры. Как лично мне кажется, на работе следует работать, а не искать способы нарушения трудовой дисциплины.

среда, 14 ноября 2012 г.

Ваш Squid может работать быстрее

Я достаточно наслушался в последнее время аргументов об отсутствии необходимости проксирования интернет-соединений. Если отбросить всю околопрофессиональную шелуху, то основной довод, который выкристаллизовывается из этой мути, следующий: прокси-сервера утратили свою кэширующую функцию и выродились до чистого контроля доступа и учетно-статистических функций. В связи с тем, в частности, что латентность кэша превосходит латентность канала внешнего интернет-доступа.

Позволю себе не согласиться с этим доводом. 

Возможно, при соединениях вида "Интернет дома в одно лицо" (хотя это тоже спорно), это и так. Однако изобилие какого-либо ресурса отнюдь не означает, что надо швыряться этим ресурсом направо и налево. Кроме того, всегда предпочтительно и даже желательно иметь запас ресурса, чем не иметь оного.

Поясню свою позицию. Допустим, у вас в наличии локальная сеть. Из 10-100-1000-или более станций. С одной точкой доступа в интернет, скоростью, допустим, 1 Гбит (хотя это канал, скорее, провайдерского уровня. Но допустим). В локальной сети у вас 6я кабельная категория и сетевая активка 1 Гбит. Как вы думаете, какой процент одинаковых интернет-запросов у пользователей подобной сети - это раз, и два - насколько велик сейчас в относительном исчислении интернет-контент по отношению, скажем, к 1996му году?

Считать не надо. Просто прикиньте - ваши 1000 пользователей в 9 утра одновременно, придя на работу, ломятся в социалки. 1000 гигабит вливаются в канал 1 Гбит внешнего доступа. Как вы считаете, они вот так вот, без тормозов, попадут туда? Это помимо того факта, что фактически будут качаться 1000 копий одного и того же контента.

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

Как?

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

Приблизительно шестигодичный опыт поддержки разнообразных прокси на основе Squid позволил выработать некоторые общие и частные подходы к построению и конфигурированию серверов с минимальной возможной латентностью (оставим пока за кадром вопросы фильтрации контента и его антивирусных проверок на лету посредством ClamAV).

Давайте попробуем обобщить эти подходы.

Выбор оборудования

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

Первое. Забудьте про барахло. Выбирайте приличный стоечный сервер серверного класса - он будет работать круглосуточно долгие годы с приличной нагрузкой, соответственно, качество железа должно быть на высоте. Если, конечно, вы не желаете танцевать каждый месяц или неделю при выходе из строя или отказе какого-либо компонента консьюмерского класса.

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

Важно - про RAID, кроме 10, забудьте.

Третье. Операционная система может быть любой, при условии, что это не Windows.

По моему опыту, сервер 1RU с 4 процессорами/ядрами и 4 Гб памяти, 1-2 сетевыми интерфейсами 1 Гбит, с парой дисков, подключенных к двум контроллерам ввода-вывода (то есть способными работать одновременно) вполне удовлетворителен в качестве кэширующего прокси для сети до 1000 рабочих станций без сколько-нибудь выраженной перегрузки. Если мы говорим о Squid.

Настройки OS

Поскольку речь идет об инфраструктурном сервере, находящимся на границе периметра, следует в обязательном порядке выполнить его минимизацию и харденинг. А также принять другие меры по защите от внешнего и несанкционированного доступа. Важно - доступ из интернета к вашему прокси должен отсутствовать!

Но вернемся к производительности. Минимизация ОС имеет не очевидное следствие - вы освобождаете оперативную память от ненужных сервисов и служб для кэширования. По тем же соображениям нежелательно держать на сервере кэша какие-либо не относящиеся к нему сервисы, особенно тяжеловесные - типа VPN, почты итп. И, тем более, запихивать его в облачные инфраструктуры. Помните? Мы говорим о латентности.

Всегда помните о законах сохранения! - они действуют в IT! Процессы выполняются не на Великом Небесном Сервере, а здесь и сейчас - на ЭТОМ процессоре, размещаются в ЭТОЙ оперативной памяти, обращаются к ЭТОМУ диску.

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

Следует также позаботиться о достаточном количестве файловых дескрипторов для пользователя, от которого мы намерены исполнять наш прокси-сервер. В противном случае мы получим узкое место, созданное собственными руками. А также об адекватных настройках IPC, если таковые имеются в наличии на выбранной платформе. Конкретно - нас интересует достаточная степень параллелизма процессов на нашем сервере. Если допустимо использовать термин из РСУБД в такой области.

Конкретный пример в случае Solaris 10.

Параметры /etc/system:

set zfs:zfs_arc_max=1073741824 
set zfs:zfs_immediate_write_sz=1000000000 
set zfs:zvol_immediate_write_sz=1000000000 

set maxphys=1048576 

set rlim_fd_max=65536 
set rlim_fd_cur=4096 
set pidmax=65536 set 
max_nprocs=65536 
set maxuprc=32767

Обратите внимание на ограничение размеров ARC (Да, мы используем ZFS). Что касается параметров собственно ZFS для кэша, то они следующие:

root @ ktulhu / # zfs get all data/cache
NAME        PROPERTY              VALUE                  SOURCE
data/cache  type                  filesystem             -
data/cache  creation              Thu Aug 18 14:29 2011  -
data/cache  used                  22.5G                  -
data/cache  available             77.5G                  -
data/cache  referenced            37K                    -
data/cache  compressratio         1.00x                  -
data/cache  mounted               yes                    -
data/cache  quota                 100G                   local
data/cache  reservation           none                   default
data/cache  recordsize            4K                     local
data/cache  mountpoint            /data/cache            default
data/cache  sharenfs              off                    default
data/cache  checksum              on                     default
data/cache  compression           off                    default
data/cache  atime                 off                    inherited from data
data/cache  devices               on                     default
data/cache  exec                  off                    inherited from data
data/cache  setuid                off                    inherited from data
data/cache  readonly              off                    default
data/cache  zoned                 off                    default
data/cache  snapdir               hidden                 default
data/cache  aclinherit            restricted             default
data/cache  canmount              on                     default
data/cache  shareiscsi            off                    default
data/cache  xattr                 on                     default
data/cache  copies                1                      default
data/cache  version               5                      -
data/cache  utf8only              off                    -
data/cache  normalization         none                   -
data/cache  casesensitivity       sensitive              -
data/cache  vscan                 off                    default
data/cache  nbmand                off                    default
data/cache  sharesmb              off                    default
data/cache  refquota              none                   default
data/cache  refreservation        none                   default
data/cache  primarycache          all                    default
data/cache  secondarycache        none                   inherited from data
data/cache  usedbysnapshots       0                      -
data/cache  usedbydataset         37K                    -
data/cache  usedbychildren        22.5G                  -
data/cache  usedbyrefreservation  0                      -
data/cache  logbias               latency                inherited from data
data/cache  sync                  standard               default
data/cache  rstchown              on                     default

Обратите внимание на размер записи и параметры primarycache и secondarycache. Дабы не разжевывать подробно, отсылаю интересующихся к документации, а здесь лишь скажу - так надо.

Настройки Squid

Большинство настроек Squid, которыми ньюфаги обмениваются в интернете, выглядят так, будто их выкопали из криокамеры и взяли с машинки на Pentium-I с 512 мегабайтами оперативной памяти. 

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

Я не буду приводить полный конфиг продуктивного Squid, а выделю лишь ключевые параметры, непосредственно касающиеся производительности.

# -------------------------------------
# Store parameters
# -------------------------------------
# Uncomment and adjust the following to add a disk cache directory.

cache_dir diskd /data/cache/d1 16384 16 256 Q1=72 Q2=64
cache_dir diskd /data/cache/d2 16384 16 256 Q1=72 Q2=64
cache_dir diskd /data/cache/d3 16384 16 256 Q1=72 Q2=64
cache_dir diskd /data/cache/d4 16384 16 256 Q1=72 Q2=64

Используем механизм асинхронных дисковых обменов Squid, в нашем случае - DISKD. Значение и смысл настроек достаточно хорошо разжеваны в интернете, не будем повторяться. Напоминаю, что топология нашей дисковой системы - полное зеркало из двух дисков на двух раздельных контроллерах ввода-вывода. В данном конкретном примере мы выбрали удовлетворительную конфигурацию, которая позволяет нашим четырем процессорам/ядрам одновременно выполнять ввод-вывод в случае максимальной загрузки нашего кэша практически без ожидания.

Следующая группа параметров относится к памяти. Поскольку на дворе не каменный век, а времена Web 1.0 с крошечными объектами безвозвратно канули в Лету, с учетом имеющейся в наличии оперативной памяти, установим следующие параметры прокси:

# ------------------------------------- 
# Memory parameters 
# ------------------------------------- 
cache_mem 512 Mb 
#memory_pools off 
memory_pools_limit 100 MB 
maximum_object_size 128 Mb 
maximum_object_size_in_memory 2 Mb 

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

Следующая группа параметров прямо влияет на производительность:

# ------------------------------------- 
# Tuning parameters 
# ------------------------------------- 
ipcache_size 8192 
ipcache_low 95 
ipcache_high 98 

fqdncache_size 8192 

buffered_logs on 

memory_replacement_policy heap GDSF 
cache_replacement_policy heap LFUDA 


cache_swap_high 98 
cache_swap_low 95 

negative_ttl 15 minutes 
positive_dns_ttl 15 hours 
negative_dns_ttl 15 minutes 

store_avg_object_size 64 KB 

pipeline_prefetch on 

shutdown_lifetime 1 second 

#offline_mode off 

# Turn it on till cache populated 
# Default is off 
ignore_ims_on_miss on 

zero_buffers off 

Прошу обратить внимание, что данные настройки целиком нацелены на  минимизацию накладных расходов, повышение коэффициента кэш-попаданий, устранение ненужных операций (zero_buffers) и задержек (shutdown_lifetime).

Отдельный вопрос - кэширование контента. Как мы говорили выше, вопрос фильтрации нас пока не интересует. Интересует эффективное кэширование любого мало-мальски тяжеловесного контента. К которому, к сожалению, можно уже отнести не только ролики с Ютуба, но и компоненты веб-страниц. В моей практике неоднократно попадались случаи многомегабайтных JS, плюс множество перекрестных ссылок, тянущих за собой гигантские социальные API. Как следствие, полный объем главной страницы какого-либо наугад взятого крупного сайта влегкую потянет на несколько десятков мегабайт.

# Common captcha acl 
acl captcha urlpath_regex -i ^captcha 

# Media and video acls 
acl youtube dstdomain .youtube.com 
acl media rep_mime_type -i video/flv 
acl mediapr urlpath_regex \.flv(\?.*)?$ 
acl media rep_mime_type -i ^application/x-shockwave-flash$ 
acl mediapr urlpath_regex \.swf(\?.*)?$ 
# Real audio acls acl RealAudio_mime 
req_mime_type application/x-pncmd 
# The keyword for all youtube video files are "get_video?", "videodownload?" and "videoplayback" plus the id 
acl store_rewrite_list urlpath_regex \/(get_video\?|videodownload\?|videoplayback.*id) 

....

# Cache directives 
cache allow youtube all 
cache allow media all 
cache allow mediapr all 
cache allow POST RealAudio_mime all 
cache deny localapache all 
cache deny captcha all 

.... 

# ------------------------------------- 
# Content parameters 
# ------------------------------------- 
# Break HTTP standard for flash videos. Keep them in cache even if asked not to. refresh_pattern -i \.flv$ 10080 90% 999999 ignore-no-cache override-expire ignore-private 
# Apparently youtube.com use 'Range' requests 
# - not seen, but presumably when a video is stopped for a long while then resumed, (or fast-forwarded). 
# - convert range requests into a full-file request, so squid can cache it 
# NP: BUT slows down their _first_ load time. 
quick_abort_min -1 KB 

# Youtube's videos 
refresh_pattern (get_video\?|videoplayback\?|videodownload\?) 5259487 99999999% 5259487 override-expire ignore-reload ignore-private negative-ttl=0 

# Add any of your own refresh_pattern entries above these. 
refresh_pattern -i \.js(\?.*)?$ 43200 100% 43200 
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 
refresh_pattern . 43200 100% 43200 override-expire override-lastmod reload-into-ims ignore-no-cache ignore-private ignore-auth 

.... 

# ------------------------------------- 
# Rewriter parameters 
# ------------------------------------- 
# Storeurl settings 
storeurl_access allow store_rewrite_list 
storeurl_access deny all 
storeurl_rewrite_program /usr/local/squid/bin/storeurl.pl storeurl_rewrite_children 16 
storeurl_rewrite_concurrency 10 
# SquidGuard rewriter 
#url_rewrite_program /usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf 
# SquidClamAV rewriter 
url_rewrite_program /usr/local/bin/squidclamav 
url_rewrite_children 96

Мы сознательно нарушаем ряд стандартов HTTP для повышения коэффициента кэш-попаданий. А также используем функциональность storeurl для эффективного кэширования роликов Ютуба по самоочевидной причине (если мы договорились не блокировать их). Большинство вышеприведенных параметров не нуждаются в комментировании. Мы молча кэшируем на 1 месяц большую часть контента, включая JS (в том числе намеренно оформленные для обхода кэширования), переписываем динамические ссылки Ютуба в статические и сохраняем их в кэше.

Подчеркну, что данные параметры относятся к Squid второй ветки, конкретно - 2.9. Ветка 3 имеет сильно измененные параметры с фактическим запретом на использование нарушающих стандарты директив, однако она и устроена иначе и требует немного иной настройки. Однако, в силу того, что ветка 3 все еще не стабилизировалась в достаточной для продуктивного применения степени, мы ее пока не рассматриваем.

Заключение

Рассмотренные в статье подходы позволили добиться весьма эффективной работы кэширующего прокси с минимальной латентностью. Фактически пользователи субъективно не ощущают присутствия кэша. Объективные показатели следующие. Для сети из 50 высокоактивных пользователей, при скорости внешнего канала 2 Мбит, и внутренней сети 1 Гбит и прогретом кэше, максимальная латентность полного соединения не превышает 0,1-0,2 сек. Собственная латентность кэша составляет 0,02-0,05 сек. Коэффициент кэш-попаданий колеблется в диапазоне 48-64%.

суббота, 10 ноября 2012 г.

Squid: Анонимен ли ваш прокси?

Вообще среди примерно половины (по моим оценкам) использующих Squid как-то не принято писать мало-мальски продвинутые конфигурации. Я воздержусь от личных оценок, с чем это связано, и хочу рассмотреть два вопроса.

Вопрос первый. Как скрывать инфраструктуру внутренней сети посредством прокси от большого злобного интернета? (само собой разумеется, все понимают, как необходимость этого, так и проистекающие отсюда же недостатки)

Ну, во-первых, надо собрать сквид определенным образом (привожу свою конфигурацию):

squid @ ktulhu ~ $ squid -v Squid Cache: Version 2.7.STABLE9-20110824 configure options: '--disable-unlinkd' '--enable-default-err-language=Russian-1251' '--enable-err-languages=Russian-1251 English' '--enable-follow-x-forwarded-for' '--enable-ipf-transparent' '--enable-storeio=ufs,diskd' '--enable-delay-pools' '--enable-async-io=4' '--prefix=/usr/local/squid' '--enable-external-acl-helpers=ip_user' '--enable-removal-policies=lru,heap' '--enable-large-cache-files' '--with-large-files' 'CC=gcc' 'CFLAGS=-O2 -march=i686 -L/usr/local/lib -R/usr/local/lib -L/usr/local/ssl/lib -R/usr/local/ssl/lib -L/usr/openwin/lib -R/usr/openwin/lib -I/usr/local/rrdtool-1.4.2/include -I/usr/local/BerkeleyDB.4.7/include -I/usr/local/mysql/include' 'LDFLAGS=-L/usr/local/lib -R/usr/local/lib -R/usr/lib -L/usr/lib -R/usr/openwin/lib -L/usr/openwin/lib -L/usr/local/ssl/lib -R/usr/local/ssl/lib -L/usr/X11R6/lib -R/usr/X11R6/lib -L/usr/local/BerkeleyDB.4.2/lib -R/usr/local/BerkeleyDB.4.2/lib -L/usr/local/mysql/lib -R/usr/local/mysql/lib' 'CPPFLAGS=-I/usr/local/include -I/usr/local/ssl/include -I/usr/local/include/ncurses -I/usr/openwin/include -I/usr/local/rrdtool-1.4.2/include -I/usr/local/BerkeleyDB.4.2/include -I/usr/local/include/pcap -I/usr/local/include/freetype2' '--with-build-environment=default' 

Вообще говоря, для нашей цели критичен лишь один параметр - enable-follow-x-forwarded-for. Как видно из конфигурации, это транспарентный прокси, соответственно, когда мы говорим об анонимизации соединений, речь идет исключительно о протоколе HTTP - другие протоколы могут светить инфраструктуру и детали сети.

Во-вторых, надо включить в конфигурации прокси следующие параметры:

# Hide internal networks details outside 
forwarded_for off 
header_access X-Forwarded-For deny all 
header_access Forwarded-For deny all 
header_access Via deny all 

Прошу обратить внимание, что данными параметрами следует и ограничиться - иначе перестанут работать многие функциональные вещи посещаемых сайтов.

Собственно говоря, для достижения нашей цели этого и достаточно, в чем нетрудно убедиться:





Вопрос второй. Для одного моего знакомого хочу сделать пояснение. В данной конфигурации, при наличии локальной сети, работающей с веб-приложением через точку доступа, оснащенную подобным проксированием, все до единого соединения с веб-сервером (и, следовательно, с базой данных) будут фиксироваться как исходящие из одного IP-адреса - внешнего адреса соединения. Что может привести к невозможности привязки конкретных рабочих станций к схемам аутентификации, аудита и прочее.

Ну, и напоследок, К.О. обращает внимание аудитории на тот очевидный факт, что подобный прокси (как и вообще любой другой) не должен быть легко доступен извне - и соответствующим образом защищен и захарденен, в противном случае вы сделаете ценный подарок хакерам.

пятница, 9 ноября 2012 г.

Squid: parseHttpRequest - unsupported method

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

Вот как это выглядит:


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

В качестве ответа на вопрос, как это побороть, даже гуглить не надо. Достаточно открыть дефолтовый конфиг с комментариями и просто внятно почитать его:


Что ж, проблема понятна. Предупреждений нам не надо, коль скоро пользователи не прибегают с жалобами, значит, УНВР. Отключим релакснутый парсер и переконфигурируем кэш. 

Вуаля - все ок:


Как видим, все решилось в одну минуту. Пользуйтесь на здоровье.

среда, 7 ноября 2012 г.

YouTube жжот

Намедни я натолкнулся на совершенно занятную выдачу результатов поиска:

*запрос был "не проигрывается видео YouTube" :)

Нет, я понимаю, что пользователи Ютуба никогда не слышали самый короткий анекдот на планете "pkunzip.zip". Я понимаю также, что выросшее Generation "Ы" с рождения страдает дислексией. "Что ты умничаешь, ты рукой покажи!"

Но то, что это примет характер клинической эпизоотии, я даже и вообразить себе не мог. 

(откровенно веселюсь)

Это пять, ребята! :)))))))))))))

Продолжайте в том же духе - и мы придем к наскальной живописи еще в этом столетии! :))))))))


Мне в конце 90х эпизодически попадались такие личности, которые, получив e-mail, немедленно перезванивали, чтобы им устно сказали то, что написано в письме. :)

Выросло поколение, воспитанное кинескопом и только им. Искать текст, читать текст и извлекать из него информацию мы уже не умеем. Только из видеорядов, сопровождаемых пока еще связной речью (хотя с последним я тоже готов уже поспорить, глядя на клипы, которые мой сын смотрит на том же Ютубе). Видеокурсы на любую тему! Пари держу на 5 биткоинов, скоро появится видеокурс по онанизму. ;)

"О, дивный новый мир!" 

Гагарин долетался, а мир докатился. :)))))))))))))))

PS. ЧСХ, цитаты из классиков уже давно никто не узнает - надо обязательно давать пруфлинк на Вики или указывать автора и название произведения. Причем первое предпочтительно - ваша память пруфом не считается. Недавно я был потрясен, случайно наткнувшись на "Снобе", как девушка 30 с чем-то лет, претендующая на интеллигентность и высочайшуюповышенную культуру, не узнала легендарную и известную любому русскоговорящему индивидууму старше 40 лет цитату из "12 стульев" Ильфа и Петрова. Даже глаза протер - не мерещится ли мне. Ей-богу, не вру! Я плакал, я рыдал, я обливался горючими слезами. "... а что касается этих ин...ин...интуальных индексов, то у них этих интуальных индексов отродясь не существовало!"

четверг, 1 ноября 2012 г.

Запрет кэширования reCAPTCHA в Squid

Неожиданно оказалось, что с директивой "кэшировать все в течение месяца" пользователи сквида не могут пройти reCAPTCHA. И, соответственно, попасть на многие уютненькие.

Что ж, запретим сквиду кэшировать соответствующий сервис и его компоненты.

Сделаем просто. Напишем регулярное выражение для acl и соответствующую директиву:

# reCAPTCHA acl 
acl recaptcha urlpath_regex ^/recaptcha 

cache deny recaptcha all

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

Ну и сквид не забыть переконфигурировать. ;)

среда, 31 октября 2012 г.

Sapienti Sat

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

Если блокировка выходных нод Tor делается сравнительно дешево и сравнительно сердито, со  входными ситуация несколько хуже.

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

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

Ну, для начала, в помощь государству, можно сильно затруднить соединение клиентов Tor в локальной сети с точками входа средствами Squid:

acl numeric_IPs url_regex ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+ 
http_access deny CONNECT numeric_IPs all

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

Однако, Tor не та вещь, которую легко удержать в наморднике. В сети Tor как раз на подобный случай существует такая штука, как бриджи:






Как видим, для сапиенса, оборудованного мозгом, нет ничего невозможного. :) Сервер вы, конечно, в правильно построенной сети не создадите, однако выйти клиентом вполне сможете при почти любой политике LAN или ISP.

Пользователи, желающие воспользоваться данным методом. Хочу заметить специально для вас - ваш поход за свободой под Tor незамеченным системными администраторами не останется. ISA фиксирует соединения с сетью Tor, другие системы проксирования также видят факт установления соединения с сетью Tor и запуск клиента по весьма характерным первым соединениям. Поэтому шалить можно только в том случае, если вам категорически за это ничего не будет. Поскольку то, что вы творите внутри Tor, видеть можно лишь с реально большим трудом (это чрезвычайно затруднительно, хотя и не могу сказать, что абсолютно невозможно), презумпция виновности будет действовать практически во всех случаях.

Нет, спасибо мне говорить не надо. Лучше сделайте небольшое пожертвование за ценную идею:
Have fun! ;)

понедельник, 29 октября 2012 г.

Новый протокол zINSTREAM в ClamAV и редиректоры Squid

Так получилось, что я достаточно долго не подходил к своим прокси-серверам. А когда, наконец, подошел, то обнаружил, что мир изменился - и разработчики ClamAV поменяли протокол взаимодействия с демоном, вследствие чего проверка "на лету" перестала работать.

Строго говоря, протокол изменен давно. На SPARC у меня проверка с редиректором SquidClamav не работала с весны, причем редиректор вылетал с дампом.

Неоднократное вскрытие показало, что проблема зарыта в редиректоре. Который не мог связаться с демоном Clam из-за того, что в том сменился протокол - был STREAM, стал zINSTREAM.

Поскольку проверка файлов "на лету" нам по-прежнему нужна, решаем проблему. Большое спасибо автору SquidClamav Gilles Darold, который отреагировал на уведомление молниеносно и собрал новые версии SquidClamav (Обе ветви - и 5.x и 6.x).

Для Squid 3 протокол zINSTREAM поддерживается в версии 6.10, для Squid 2 в версии 5.11.

Собирается обычным образом, конфигурационные файлы править не нужно.

Стоит отметить, что, на субъективный взгляд, новый протокол выполняет передачу файлов  на проверку ощутимо быстрее, и время отклика сервера стало меньше.

среда, 17 октября 2012 г.

Как почистить кэш Squid

Нет, не целиком удалить. А вычистить оттуда лишнее, то, что не нравится или нужно освежить.

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

Напишем красивый ленивчик, не содержащий лишних и ненужных движений:


#!/bin/sh
# Purge object(s) from Squid cache
AWK=`which awk`
GREP=`which grep`
XARGS=`which xargs`
SQUIDCLIENT="/usr/local/squid/bin/squidclient"

SQUID_LOG="/data/cache/log/access.log"

$GREP "$1" $SQUID_LOG | $AWK '{print $7}' | $XARGS $SQUIDCLIENT -m PURGE

Порядок. Положить в /usr/local/bin, дать права на выполнение и пользоваться на здоровье. Аргументом можно задавать домен, маску имени, расширение файлов.

Если не хочется на отсутствующий объект получать ругань клиента - добавьте опцию -s.

пятница, 21 сентября 2012 г.

Solaris 10: ZONECFG - Segmentation Fault

В свое время я написал серию статей о конфигурировании зон Solaris 10. Недавно мне пришлось тряхнуть стариной и вспомнить о своем конфигураторе. И вдруг - внезапно! - обнаружилось, что ни на одной машине мой конфигуратор не работает.

Обнаружилась занятная ошибка:

root @ pegasus /patch # zoneinst.sh zone1.cfg
Segmentation Fault - core dumped
zone1: No such zone configured
Cannot set a resource-specific property from the global scope.
The end command only makes sense in the resource scope.
zone1: No such zone configured
zone1: No such zone configured
zone1: No such zone configured
Cannot set a resource-specific property from the global scope.
Cannot set a resource-specific property from the global scope.
Cannot set a resource-specific property from the global scope.
The end command only makes sense in the resource scope.
zone1: No such zone configured
Cannot set a resource-specific property from the global scope.
Cannot set a resource-specific property from the global scope.
Cannot set a resource-specific property from the global scope.
Cannot set a resource-specific property from the global scope.
The end command only makes sense in the resource scope.
zone1: No such zone configured
Cannot set a resource-specific property from the global scope.
Cannot set a resource-specific property from the global scope.
The end command only makes sense in the resource scope.
Zone zone1 configured.
______________________
Press to install zone or to cancel.
^C

Более того, ошибка проявлялась сразу же при первом запуске zonecfg:

+ /usr/sbin/zonecfg -z zone1 create; set autoboot=true; set zonepath=/data/zone1; 
Segmentation Fault - core dumped


Вскрытие сначала привело сюда:

root @ ktulhu /patch # ldd /usr/sbin/zonecfg libz.so.1 => /usr/local/lib/libz.so.1 libz.so.1 (SUNW_1.1) => (version not found)

А затем сюда:

root @ ktulhu /patch # find / -name libz.so.1
/usr/lib/amd64/libz.so.1
/usr/lib/libz.so.1
/usr/local/lib/libz.so.1
^C
root @ ktulhu /patch # echo $LD_LIBRARY_PATH
/lib:/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.2/lib:
root @ ktulhu /patch # export LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH
root @ ktulhu /patch # echo $LD_LIBRARY_PATH
/usr/lib:/lib:/usr/local/lib:/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.2/lib:
root @ ktulhu /patch # ldd /usr/sbin/zonecfg
libzonecfg.so.1 => /usr/lib/libzonecfg.so.1
libl.so.1 => /usr/lib/libl.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libtecla.so.1 => /usr/lib/libtecla.so.1
libzfs.so.2 => /usr/lib/libzfs.so.2
libbrand.so.1 => /usr/lib/libbrand.so.1
libc.so.1 => /usr/lib/libc.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
libuuid.so.1 => /usr/lib/libuuid.so.1
libnvpair.so.1 => /usr/lib/libnvpair.so.1
libsysevent.so.1 => /usr/lib/libsysevent.so.1
libsec.so.1 => /usr/lib/libsec.so.1
libpool.so.1 => /usr/lib/libpool.so.1
libscf.so.1 => /usr/lib/libscf.so.1
libproc.so.1 => /usr/lib/libproc.so.1
libuutil.so.1 => /usr/lib/libuutil.so.1
libxml2.so.2 => /usr/lib/libxml2.so.2
libmp.so.2 => /usr/lib/libmp.so.2
libmd.so.1 => /usr/lib/libmd.so.1
libcurses.so.1 => /usr/lib/libcurses.so.1
libm.so.2 => /usr/lib/libm.so.2
libdevinfo.so.1 => /usr/lib/libdevinfo.so.1
libdevid.so.1 => /usr/lib/libdevid.so.1
libgen.so.1 => /usr/lib/libgen.so.1
libavl.so.1 => /usr/lib/libavl.so.1
libefi.so.1 => /usr/lib/libefi.so.1
libadm.so.1 => /usr/lib/libadm.so.1
libumem.so.1 => /usr/lib/libumem.so.1
libdoor.so.1 => /usr/lib/libdoor.so.1
libexacct.so.1 => /usr/lib/libexacct.so.1
librtld_db.so.1 => /usr/lib/librtld_db.so.1
libelf.so.1 => /usr/lib/libelf.so.1
libctf.so.1 => /usr/lib/libctf.so.1
libpthread.so.1 => /usr/lib/libpthread.so.1
libz.so.1 => /usr/lib/libz.so.1

То есть, для устранения ошибки достаточно было правильно установить переменную LD_LIBRARY_PATH, причем желательно это сразу сделать в глобальном профиле /etc/profile.

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

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

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

среда, 19 сентября 2012 г.

Анатомия ZFS часть VI

При написании данного цикла статей использовался документ ZFS On-Disk Specification,Sun Microsystems

1.4.         Adaptive Replacement Cache (ARC)

Адаптивный замещающий кэш (Adaptive Replacement Cache, ARC) – совершенно новое слово в технологиях кэширования*.
Первоначальный алгоритм разработан Мегиддо и Модха (N. Megiddo, D. Modha) в 2003 году (представлен на FAST). Он реализован в ZFS с несколькими существенными отличиями:
·        Согласно модели первоначального алгоритма, любая страница является выгружаемой. Это делает алгоритм вытеснения очень простым – выгружается всегда последняя страница кэша. В ARC используется более сложная модель: часть страниц остается заблокированной на основе подсччета количества ссылок на них. Блокировка вытеснения снимается лишь в отсутствие внешних ссылок на страницу. Существуют периоды, когда вытеснение страниц запрещается. В это время изменение размеров кэша запрещено. С целью избежания неограниченного роста кэша реализовано так называемое «охлаждение кэша», основанное на замедлении загрузки кэша пока запрос на пространство не сможет быть удовлетворен
·        Первоначальный алгоритм использует кэш фиксированного размера. Страницы вытесняются когда кэш полон и начинают фиксироваться кэш-промахи. В ARC используется кэш переменного размера, однако используемый с таким расчетом, чтобы освобождать память по первому требованию в случае поступления запросов на память от операционной системы. Иными словами, кэш будет сокращаться в случае исчерпания памяти, доступной операционной системе
·        Первоначальная модель предполагает фиксированный размер страниц. Модель ARC использует страницы переменного размера (от 512 байт до 128 Кбайт), что позволяет очень просто удовлетворять запросы на память – достаточно освободить страницу необходимого размера. Это позволяет лучше использовать оперативную память и заполнять ее более полно в процессах загрузки и вытеснения страниц**.

ARC использует две модели освобождения страниц – консервативную и агрессивную:

typedef enum arc_reclaim_strategy { 
 ARC_RECLAIM_AGGR, /* Aggressive reclaim strategy */ 
 ARC_RECLAIM_CONS /* Conservative reclaim strategy */ 
 } arc_reclaim_strategy_t;

Консервативная модель используется в обычном режиме работы, агрессивная задействуется в случаях, когда давление на память со стороны операционной системы растет.Интервал проверки возможности увеличения размеров кэша по умолчанию составляет 60 секунд. Страничный буфер ARC может находиться в одном из 6 возможных состояний:

· ARC_anon - анонимный
· ARC_mru  - недавно использовался, кэширован
· ARC_mru_ghost            - давно использовался, больше не в кэше
· ARC_mfu           - часто использовался, в настоящее время в кэше
· ARC_mfu_ghost            - часто использовался, больше не в кэше
· ARC_l2c_only   - существует в кэше второго вроня, но не в одном из других состояний

Когда буфер не имеет ни одной внешней ссылки, он присоединяется к одному из данных списков. Только буферы без ссылок могут быть удалены или вытеснены. В каждом из списков данные разделены на группы – метаданные и собственно данные.
Анонимные буферы – это буферы, с которыми не ассоциированы никакие DVA (см. Главу 1.2.1). Данные буферы содержат грязные копии блоков, которые должны быть записаны в стабильный пул. По определению, данные буферы считаются ссылаемыми (на них существуют ссылки) и являются частью списка, который не может быть освобожден (ARC_mru). В общем случае, они получают DVA при записи и помещаются в список ARC_mru.
ARC использует модель интеллектуальной адаптивной предвыборки и быстрого прогрева (turbo warmup).
Мы не будем в деталях обсуждать механизмы предвыборки, заметим лишь, что требования по оперативной памяти к ARC достаточно высоки, однако это не мешает эффективно использовать ARC на системах с объемом оперативной памяти 1-2 Гб.
При нормальных условиях ARC, используя механизмы быстрого прогрева, достаточно быстро заполняет свободную оперативную память. Такое же поведение характерно и для кэшей UFS, разница, однако, в том, что память, занимаемая буферами UFS, считается (и показывается) свободной. Следует помнить, однако, что ZFS освобождает память по первому требованию, следовательно, данная память может считаться условно свободной.
ZFS использует кэширование на двух уровнях –файловом уровне и уровне vdev. Используя DTrace, ZFS определяет паттерны чтения программных модулей, и затем формирует очереди предвыборки в соответствие с этими паттернами. Таким образом обеспечивается интеллектуальная предвыборка данных в соответствие с запросами приложений.
В некоторых приложениях, использующих собственные механизмы кэширования и/или нуждающихся непосредственно в свободной памяти, существует механизм уменьшения предпочитаемого размера ARC до заданной величины.

Это ограничение устанавливается параметром zfs:zfs_arc_max файла /etc/system, размер задается в байтах, например: 

set zfs:zfs_arc_max=1073741824
Существует утилита  Бена Роквуда (Ben Rockwood, benr@cuddletech.com), arc_summary.pl, написанная на perl, позволяющая получать аггрегированную статистику работы ARC:
 
root @ pegasus / # arc_summary.pl
System Memory:
         Physical RAM:  1491 MB
         Free Memory :  346 MB
         LotsFree:      23 MB
 
ZFS Tunables (/etc/system):
 
ARC Size:
         Current Size:             198 MB (arcsize)
         Target Size (Adaptive):   474 MB (c)
         Min Size (Hard Limit):    64 MB (zfs_arc_min)
         Max Size (Hard Limit):    474 MB (zfs_arc_max)
 
ARC Size Breakdown:
         Most Recently Used Cache Size:          49%    236 MB (p)
         Most Frequently Used Cache Size:        50%    237 MB (c-p)
 
ARC Efficency:
         Cache Access Total:             76283
         Cache Hit Ratio:      91%       69456          [Defined State for buffer]
         Cache Miss Ratio:      8%       6827           [Undefined State for Buffer]
         REAL Hit Ratio:       80%       61217          [MRU/MFU Hits Only]
 
         Data Demand   Efficiency:    95%
         Data Prefetch Efficiency:    23%
 
        CACHE HITS BY CACHE LIST:
          Anon:                       11%        8207                   [ New Customer, First Cache Hit ]
          Most Recently Used:         22%        15867 (mru)            [ Return Customer ]
          Most Frequently Used:       65%        45350 (mfu)            [ Frequent Customer ]
          Most Recently Used Ghost:    0%        16 (mru_ghost) [ Return Customer Evicted, Now Back ]
          Most Frequently Used Ghost:  0%        16 (mfu_ghost) [ Frequent Customer Evicted, Now Back ]
        CACHE HITS BY DATA TYPE:
          Demand Data:                67%        47080 
          Prefetch Data:               0%        556 
          Demand Metadata:            20%        13925 
          Prefetch Metadata:          11%        7895 
        CACHE MISSES BY DATA TYPE:
          Demand Data:                35%        2407 
          Prefetch Data:              26%        1802 
          Demand Metadata:            18%        1257 
          Prefetch Metadata:          19%        1361 
---------------------------------------------
 
Данная утилита является одной из наиболее удобных и используется автором для мониторинга систем, использующих ZFS.

1.4.         Тома ZFS (ZVOL)

Тома ZFS (ZVOL) предоставляют механизм создания логических устройств. Тома ZFS экспортируются как блочные устройства и могут использоваться подобно другим блочным устройствам:

root @ pegasus / # zfs list |grep test
root @ pegasus / # zpool status data2
  pool: data2
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        data2       ONLINE       0     0     0
          c4t0d0    ONLINE       0     0     0
        logs
          c4t1d0    ONLINE       0     0     0

errors: No known data errors
root @ pegasus / # zfs create -V 1g data2/test1
root @ pegasus / # zfs create -V 1g data2/test2
root @ pegasus / # zfs list | grep test
data2/test1                       1G  3.00G    16K  -
data2/test2                       2G  3.00G    16K  -

root @ pegasus / # newfs /dev/zvol/dsk/data2/test2       
newfs: construct a new file system /dev/zvol/rdsk/data2/test2: (y/n)? y
Warning: 2082 sector(s) in last cylinder unallocated
/dev/zvol/rdsk/data2/test:      4194270 sectors in 683 cylinders of 48 tracks, 128 sectors
        2048.0MB in 43 cyl groups (16 c/g, 48.00MB/g, 11648 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
 32, 98464, 196896, 295328, 393760, 492192, 590624, 689056, 787488, 885920,
 3248288, 3346720, 3445152, 3543584, 3642016, 3740448, 3838880, 3937312,
 4035744, 4134176
root @ pegasus / # mount -F ufs /dev/zvol/dsk/data2/test /test1
root @ pegasus / # df –h | grep test1
/dev/zvol/dsk/data2/test   1.9G   2.0M   1.9G     1%    /test1
root @ pegasus / # umount /test1
root @ pegasus / # zfs destroy data2/test2

Тома ZFS представлены как объекты типа DMU_OST_ZVOL. Объект ZVOL имеет очень простой формат и содержит два объекта: объект свойств и объект данных, DMU_OT_ZVOL_PROP и DMU_OT_ZVOL соответственно. Оба объекта имеют статически назначенный ID. Объекты описаны ниже:
· DMU_OT_ZVOL_PROPZAP-объект, содержащий атрибуты тома, такие, например, как размер (volsize, может быть изменен динамически) и др.
· DMU_OT_ZVOL – объект содержит виртуальное блочное устройство

 ____________________
* Данная статья основана на исходных текстах ARC, доступных по ссылке http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/arc.c
** См. также "ARC: A Self-Tuning, Low Overhead Replacement Cache" by N. Megiddo & D. Modha, FAST 2003