Броячи на трафик в OpenVPN срещу дисков вход-изход: три различни числа

Прекарайте голям файл през тунел и броячът на интерфейса нараства с размера на файла. Нищо в това число не означава, че същият обем е достигнал диск. В тези обсъждания се сравняват три различни измервания и те отговарят на три различни въпроса: колко трафик е пресякъл мрежов слой, колко байта процес е прочел и записал чрез системни извиквания и колко работа е достигнала слоя за съхранение.

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

Три числа, които се смесват

Броячите на интерфейса описват трафика, обработван на мрежов слой. Те са правилното число за честотна лента, за размера на тунела и за модели на таксуване, които определят цена на транзита.

Броячите на символи на процеса описват байтовете, преместени чрез извиквания за четене и запис върху всеки дескриптор, включително тръби, терминали и символни устройства. Те са правилното число за въпроса колко зает е процес при границата на системното извикване и не са дисков разход.

Броячите за съхранение описват байтовете, които ядрото е опитало да премести към или от блоково устройство. Те са правилното число за планиране на капацитета, с уговорката, че ядрото документира собствените си граници на отчитане: кешираните четения не стават четения от съхранение, а запис, който по-късно бъде отменен, не става завършен запис на устройство.

Защо файловият дескриптор не е запис на диск

VPN в потребителско пространство обменя пакети с ядрото чрез устройство TUN, което е символно устройство, а не обикновен файл. Четенето от него предава пакет; записването в него вкарва пакет. Няма страница със съдържание на файл, подготвяна за съхранение, и няма включен път на файлова система.

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

cat /proc/$(pgrep -n openvpn)/io
ip -s link show tun0

Четете първия изход като натрупан от стартирането на процеса, а не като скорост. Вторият дава изгледа на интерфейса за същия трафик. Голямата разлика между двете е очаквана и не означава изтичане, опашка или грешна конфигурация.

Откъде наистина идват байтовете

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

Файлът за състояние е моментна снимка, презаписвана през интервал, така че цената му зависи от интервала и от колко записа съдържа. Той не е работещо копие на трафика на всеки клиент и съкращаването на интервала променя обема на запис, без да променя обема на трафика.

Собствеността е важна, когато търсите тези записи. Ако услугата предава съобщения на демон за журнал, журналът или файлът се записват от този демон и байтовете се появяват в отчитането на демона, а не в собствените броячи на процеса VPN. Гледането само на процеса VPN не обяснява нито дисковата активност, нито липсата ѝ.

Други участници лесно се пропускат: четене на сертификати и конфигурация при стартиране, куки, които пишат собствени записи, плъгини за отчитане, дъмпове при срив и несвързани натоварвания на същия хост. Никой от тях не бива да се оценява, като се приравнява трафикът на тунела на записаните байтове.

Как да четем всеки брояч правилно

Три подробности решават дали едно сравнение означава нещо. Идентичността на процеса е важна, защото рестартирана услуга нулира броячите си. Времевият интервал е важен, защото натрупаната цифра и графиката за секунда са различни измервания. И единицата е важна, защото текущият размер на файл за журнал също не е скорост.

grep -E 'rchar|wchar|read_bytes|write_bytes' /proc/$(pgrep -n openvpn)/io
du -sh /var/log/openvpn 2>/dev/null
journalctl --disk-usage

Ако подозирате истински записи на полезния товар, търсете компонент, чиято работа е да съхранява товара: инструмент за прихващане на пакети, прокси, което кешира тела, плъгин, който архивира. Те създават трафик към съхранение, който се мащабира с това, което се иска да записват, и принадлежат към отделно политическо решение за съхранение и достъп.

Планиране на капацитет с правилното число

Оразмерете пътя на пакетите с мрежови числа: пропускателна способност, криптографска обработка и движение на паметта. Оразмерете съхранението с изборите за наблюдаемост, които наистина сте направили: ниво на журнала, съхранение, интервал на състоянието и всяко прихващане, което е умишлено включено.

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

Сравнението, което си заслужава, е между измервания от един и същ вид. Байтове на интерфейса срещу байтове на интерфейса във времето ви казват за пътя. Записи на диска срещу капацитет за съхранение ви казват за съхранението. Кръстосаното сравнение, трафик срещу диск, само изглежда смислено и никога не е.