NFS преку TCP во UDP тунел на OpenVPN: два транспорта
Протоколот за монтирање и протоколот на тунелот се одделни поставки. Запишете ги двете, потоа одлучете дали застојот и припаѓа на датотечната служба или на носачот.
Пренесувањето на NFS разговор што користи TCP во тунел што носи UDP е сосема доследно, и ги збунува луѓето затоа што именува два транспорта истовремено. TCP е разговорот на датотечната служба помеѓу клиентот и NFS серверот. UDP е шифрираниот носач помеѓу крајните точки на VPN. Ниту еден од двата не подразбира ништо за другиот.
Запишете ги двете одделно пред да почнете да отстранувате грешки; повеќето од овие инциденти започнуваат кога некој ќе смени погрешен слој.
Два слоја, две поставки
Опцијата за монтирање proto=tcp опишува како NFS клиентот разговара со NFS серверот. Поставката proto udp во профилот на VPN опишува како крајните точки на тунелот разменуваат инкапсулирани пакети. Менувањето на опција за монтирање не го менува тунелот, а менувањето на транспортот на тунелот не го менува тоа што NFS клиентот го договорил. Потврдете ги вистинските опции за монтирање со nfsstat -m наместо со редот во fstab, и потврдете го транспортот на VPN од профилот што навистина се користи.
Потоа запишете ги во белешките за инцидентот како две одделни полиња. Привидното подобрување може да се следи само ако белешката каже кој слој се сменил.
Прелистувањето не е масовно читање
Списокот на директориум докажува дека некои операции завршиле. Тој не докажува дека долготрајно читање, пишување, заклучување или складишниот заден дел ќе завршат под исти услови. Застој на средина на голема датотека е различно набљудување од монтирање што никогаш не успева, и тие укажуваат на различни слоеви.
Опишете ја неуспешната операција точно: патека, насока, приближно место на застојот и последниот релевантен настан во дневниците на клиентот, серверот и VPN. Потоа споредете каде сообраќајот продолжува и каде запира.
MTU е хипотеза, не дијагноза
Загубата зависна од големината на пакетот е вистинска можност кога тунелот носи големи сегменти, и го создава токму моделот во кој прелистувањето работи, а читањето застанува. Сепак тој модел не докажува проблем со MTU, бидејќи истата форма се појавува кога серверот е бавен, кога огнениот ѕид прекинува долга врска поради истек на време, или кога дискот е зафатен. Тестирајте ја хипотезата со контролирана проба наместо насекаде да го намалите MTU и да прогласите победа.
Истекот на време сам по себе не кажува ништо за тоа дали UDP треба да се замени. Тоа е симптом со неколку можни сопственици.
Менувајте по една променлива истовремено
Кога споредувате транспорти, држете го работното оптоварување на NFS и сите други поставки стабилни. Менувањето на транспортот за монтирање, протоколот на тунелот и MTU во истиот сервисен прозорец дава резултат што никој не може да го припише. Изведете ја истата датотечна операција пред и потоа, и запишете го исходот на секој чекор.
Зачувајте ги и претходните вредности во тикетот. Ако промената ја влоши состојбата, враќањето треба да биде документиран број, а не нечие сеќавање како било претходно.
Читајте го слојот што откажал
Ако тунелот е подигнат, а NFS барањето чека, VPN не откажал; откажала датотечната служба. Ако тунелот паднал, неуспехот на NFS барањето е последица, а не причина. Споредувањето на линиите од дневникот од двата слоја е најбрзиот начин да се разликуваат овие два случаи, и тоа е подобро од погодување од менаџерот на датотеки.
Напишете го заклучокот како две реченици, по една за секој слој. Тоа е доволно следниот човек да го повтори тестот без повторно да изведува кој транспорт е кој.