VPN runtime в RAM не казва нищо за журналите

VPN сървър, стартиран от образ само за четене и със състоянието си в tmpfs, е реална и полезна архитектура. Също толкова лесно е да се опише като „без журнали“, което архитектурата не доказва. Мястото на съхранение определя къде живее копие; събирането и запазването определят дали запис съществува изобщо, а рестартът засяга само първото. Разделянето на тези две е целият преглед.

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

Съхранение и събиране са различни въпроси

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

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

tmpfs не е гаранция

Linux tmpfs не е физически RAM диск. Документацията на ядрото изрично посочва, че страници могат да бъдат записвани в swap, когато монтирането го позволява, така че файл в tmpfs може да достигне диск, без приложението някога да го е копирало там. mount показва дали се използва tmpfs с swap, а другите файлови системи в паметта се държат още по-различно. Четете действителните опции за монтиране, вместо да предполагате, че път под /run означава летливост.

След това опишете нещата, които преживяват рестарт по начини, които хората забравят: постоянен overlay, прикачено хранилище, образи за хибернация, дъмпове при срив и инфраструктурни снимки на цялата VM. Всяко от тях е възможно местоназначение за състояние, което сте смятали за ефимерно. Този списък е нещо за проверка, а не твърдение, че всеки хост има всички тях.

Journald има две местоназначения и препращащ механизъм

Journald илюстрира разделението добре. Летливото хранилище пази записи под /run/log/journal, постоянното — под /var/log/journal, а автоматичният режим избира между тях; действащият режим идва от работещата система, а не от описанието на образа. Превключването към летливо не изтрива това, което вече е записано постоянно. Препращането също е отделен канал: дори настройка на хранилището, която не пази нищо локално, може да предава съобщения към друга цел.

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

Какво трябва да преживее рестарт

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

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

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