Профили пользователей RDS разрастаются: где искать лишние гигабайты

Представьте бухгалтера, у которого в «Документах» лежит два гигабайта: договоры, сверки, пара таблиц с говорящими названиями вроде «итог_финал_правка3». А профиль этого же сотрудника на терминальном сервере занимает восемнадцать. Шестнадцать гигабайт — это не работа человека. Это то, что вокруг неё нарастает: кеши, остатки загрузок, локальные копии почты, временные файлы программ, которые никто не просил хранить, но и никто не просил удалять.

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

Профиль — это не одна папка, а несколько слоёв с разной судьбой

Слово «профиль» обманывает своей цельностью. Для пользователя это «мой рабочий стол и мои настройки». Для администратора внутри лежат данные принципиально разной природы:

• Работа человека: документы, файлы на рабочем столе, сохранённые черновики, которых нет больше нигде.
• Настройки: расположение окон, словари, подписи в почте, закладки. Мало места, высокая ценность.
• Кеши: то, что программа сохранила для скорости и может скачать или вычислить заново. Много места, ценность разная.
• Временное: распакованные вложения, файлы предпросмотра, остатки сеансов. Чаще всего мусор, но «чаще всего» — не «всегда».
• Локальные копии облачных данных: синхронизированные папки и почтовые кеши. Их можно восстановить с сервера-источника, но не мгновенно и не при каждом сбое источника.

Если диск растёт, вопрос «какая папка больше всех» почти бесполезен. Полезнее вопрос «какого типа данных стало больше». Это определяет и способ действия: настройки не трогают, кеши ограничивают, временное убирают, а работу человека переносят туда, где ей место, — по согласованию с самим человеком.

Где физически живёт профиль

В среде с контейнерами профилей картина добавляет ещё один слой. FSLogix, по описанию Microsoft, перенаправляет профиль на хранилище, но для приложения сохраняется представление обычного локального профиля (документация FSLogix). Программа считает, что пишет в привычный каталог пользователя, а на деле данные оказываются в контейнере на хранилище. Там же сказано, что профиль и ODFC — разные типы контейнеров; ODFC относится к данным Office, и их можно рассматривать отдельно от основного профиля. Для нас это практический факт: размер «профиля» может складываться из двух файлов-контейнеров, и растёт чаще всего не тот, на который вы смотрите.

Есть и вторая сторона. Если профили лежат на обычных папках сервера, место съедает файловая система сервера, и каждый каталог виден в Проводнике. Если в контейнерах, снаружи вы видите только размер файла контейнера, а внутри — другая арифметика. К ней мы вернёмся в разделе про закрытый профиль, потому что именно здесь скрыта самая частая ловушка: данные внутри удалили, а место на диске осталось занятым.

Как выглядит распределение места: учебный пример

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

Обратите внимание, что строки, где «сразу удалить», здесь нет. Временные файлы — самая очевидная кандидатура, но это всего шесть процентов. Крупнейшая категория — загрузки, и она же самая коварная: это не кеш, а смесь. Там может лежать установочный файл годовой давности, а может — единственная копия счёта, который человек скачал «на минутку» и с тех пор на него ссылается.

Теперь арифметика всего сервера. Пусть пользователей пятьдесят, средний профиль — те самые 18 ГБ. Получается около 900 ГБ только профилей. Если каждый профиль в среднем прирастает на 150 МБ в сутки, то в день набегает около 7,5 ГБ, за месяц — порядка 225 ГБ. Это тоже условные числа, но они объясняют важную вещь: одноразовая очистка на 100 ГБ откладывает проблему меньше чем на две недели. Либо вы снижаете скорость роста, либо чистите вечно.

Кто владелец каталога: четыре вопроса вместо одного

Прежде чем что-либо удалять, у каждой крупной папки должен появиться владелец — не в смысле прав доступа, а в смысле ответственности за содержимое. Для этого достаточно четырёх вопросов, которые вы задаёте каждому крупному каталогу.

1. Кто пишет в эту папку? Человек вручную или программа сама. Если папку наполняет программа, значит, у программы есть логика её использования, и обращаться стоит к настройкам программы.
2. Откуда это можно получить снова? Из почтового сервера, из облака, из интернета — или ниоткуда. Если «ниоткуда», это работа человека, и разговор другой.
3. Что случится, если папка исчезнет? Программа молча пересоздаст её, потребует повторной настройки или перестанет запускаться. Это нельзя выяснить, глядя только на название.
4. Когда к ней обращались в последний раз? Дата последнего изменения ничего не доказывает про ценность, но отлично показывает, живёт ли каталог или давно стал кладбищем.

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

Почему «безопасных каталогов» не бывает без проверки

Соблазн составить универсальный список «это можно удалять» понятен, но он не выдерживает встречи с реальными программами. Одно приложение хранит в каталоге кеша только пересоздаваемые данные. Другое кладёт туда же локальную базу, которой больше нигде нет, потому что разработчик решил, что «кеш» — подходящее слово для папки. Третье держит там лицензионную привязку или токены, после потери которых человеку придётся заново проходить вход, а то и обращаться к поставщику.

Поэтому правило такое: для каждого приложения, чей каталог вы собираетесь чистить, нужно подтверждение. Это может быть документация производителя, настройка самой программы («очистить кеш», «ограничить размер»), либо проверка на тестовой учётной записи, где вы удалили каталог и посмотрели, что произошло после запуска. Удалять «весь AppData» целиком не стоит никогда: там перемешаны настройки, ключи, локальные базы и кеши в одной куче, и разделять их придётся по приложениям, а не одним движением руки. Профиль работающего пользователя целиком удалять нельзя тем более: вы убираете рабочую среду у человека, у которого прямо сейчас открыты документы.

Закрытый и открытый профиль — два разных случая

Есть момент, который в очистке меняет всё: вошёл ли пользователь в систему. От ответа зависит не только риск, но и сам набор допустимых действий.

Профиль закрыт: сеанс завершён

Когда пользователь вышел и ничего не держит файлы открытыми, у вас есть время подумать. Здесь можно спокойно изучить структуру, посчитать размеры по каталогам и принять решение с владельцем в голове. Но спешить всё равно не нужно, и вот почему.

Если профили лежат обычными папками, удалённое освобождает место на диске сразу. Но если это контейнеры, ситуация иная. В документации по сжатию VHD Microsoft подчёркивает, что динамический контейнер и физически занятое место на диске необходимо различать (диагностика сжатия VHD). По смыслу это значит следующее: вы можете удалить внутри контейнера десять гигабайт, а файл контейнера на хранилище останется прежним, пока не произойдёт сжатие. С точки зрения пользователя профиль «похудел», с точки зрения хранилища — нет. Изнутри тоже легко ошибиться: показатели свободного места внутри контейнера и на томе хранилища — разные цифры, и ориентироваться стоит на тот, где у вас на самом деле кончается диск.

Та же страница описывает и ограничения. Результаты сжатия FSLogix фиксирует в журнале профиля и в событиях, так что причину, по которой место не вернулось, можно найти, а не угадывать. Фиксированный VHD этим механизмом не сжимается вовсе. А недостаток освобождаемого места — отдельная причина, по которой операция может быть пропущена: если удалять почти нечего, сжимать тоже нечего. Из этого следует практический порядок: сначала выясните, какого типа ваши контейнеры, потом чистите содержимое, потом смотрите журнал и событиях сжатия, а уже затем сравнивайте размер файла контейнера до и после. Если вы фиксированный контейнер «почистили» изнутри и удивились, что файл не уменьшился, — это не сбой, а свойство такого типа.

Профиль открыт: человек работает

Здесь действует другая логика: всё, что вы делаете, происходит рядом с живой работой. Файлы, которые кажутся неподвижными, могут быть открыты программой; кеши, которые кажутся мусором, — использоваться прямо сейчас. Удаление в таком окружении приводит либо к ошибке доступа, либо, что хуже, к тому, что программа получит неожиданно пустое место там, где ждала свои данные.

Поэтому в открытом профиле допустимы только действия, которые рассчитаны на работающую среду:

• штатные средства самих приложений: очистка кеша и ограничение его размера в настройках программы, которые пользователь или политика применяют сами;
• просьба к человеку разобрать «Загрузки» и перенести нужное — он единственный, кто знает, что из этого ценно;
• запланированные действия на выходе из сеанса, но только те, которые вы уже проверили на закрытом тестовом профиле;
• наблюдение: замер прироста по каталогам, чтобы на следующем окне обслуживания знать, что именно растёт.

Что не годится: массовое удаление «по маске» на сервере, где прямо сейчас идут сеансы; принудительное закрытие чужих файлов ради освобождения нескольких гигабайт; ручная правка внутри контейнера, который подключён к активному сеансу. Выигрыш в месте несравним с ценой несохранённого файла бухгалтера в конце квартала.

Что делать с каждой категорией из таблицы

Вернёмся к нашему учебному профилю и пройдём по строкам — не как по инструкции, а как по ответам на четыре вопроса.

Загрузки (4,3 ГБ). Крупнейшая и самая человеческая категория. Принудительной очисткой тут не обойтись: нужно договориться, где лежат рабочие файлы. Если сотрудники привыкли скачивать вложения в «Загрузки» и работать оттуда, то папка фактически стала рабочим каталогом. Решение — не стереть, а предложить другое место для рабочих файлов (общая папка с понятными правами, облачное хранилище, куда они всё равно должны складываться) и оставить «Загрузки» временной зоной. Тогда её можно ограничивать — например, квотой или регулярной просьбой разобрать.

Локальный кеш почты (3,9 ГБ). Это копия того, что хранится на почтовом сервере, и главный вопрос — насколько глубоко в прошлое нужно держать её локально. Размер кеша обычно регулируется настройками почтового клиента: можно ограничить период хранимых локально писем. Конкретный параметр и его поведение зависят от клиента и его версии, поэтому проверяйте его по документации производителя вашего клиента и на тестовой учётной записи. Если Office-данные вынесены в ODFC, то как раз этот контейнер будет расти, и им можно управлять отдельно от основного профиля — об этом шла речь выше.

Кеши браузеров (3,2 ГБ). Здесь почти всегда допустимо ограничение размера кеша политиками браузера: кеш по определению пересоздаваем. Но «почти» — важное слово: в том же каталоге пользовательских данных браузера лежат профиль, пароли, расширения. Поэтому правильное действие — не удалить каталог, а задать параметр или очистить именно кеш средствами браузера.

Кеши прочих приложений (2,4 ГБ). Вот тут нужна работа по каждому приложению. Мессенджеры, средства совместной работы, клиенты облачных папок — у каждого свои правила, и именно в этой категории встречаются «кеши», в которых лежит единственная копия чего-то нужного. Чистить их без подтверждения от производителя или тестовой проверки нельзя.

Временные файлы (1,1 ГБ). Самая простая категория, но и тут нужна оговорка: безопасно убирать только то, что не используется сейчас. Лучший момент — выход из сеанса или закрытый профиль.

Локальная копия облачной папки (0,8 ГБ). Размер небольшой, но поведение может быть неприятным: если синхронизация настроена на «всё», то каждый новый пользователь будет стягивать на сервер всё содержимое облака. Посмотрите настройки клиента: многие позволяют хранить файлы по требованию, а не целиком. Это одна из тех строк, которая сегодня маленькая, а завтра превращается в самую крупную.

Рост — это поведение, а не состояние

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

Постоянная очистка — признак того, что вы лечите следствие. Поэтому полезно перейти от вопроса «что удалить» к вопросу «почему оно пишется сюда». Каждая крупная категория из таблицы даёт свой ответ:

Каждое из этих решений убирает не гигабайты, а их источник. Лимит на кеш браузера делает так, что через неделю кеш не вырастет заново до прежнего размера. Перенос рабочих файлов из «Загрузок» в предназначенное место делает так, что очистка «Загрузок» перестаёт быть опасной. Это и есть смена парадигмы: вы не чистите быстрее, вы меняете то, что нужно чистить.

Где ограничивать, а где разделять

Есть и архитектурный ход. Раз профиль и ODFC — разные типы контейнеров, их можно рассматривать как разные зоны ответственности: личные настройки и рабочий стол в одном, тяжёлые данные Office в другом. Тогда рост второго не раздувает первый, а ограничения, мониторинг и политику обслуживания можно задавать раздельно. Это не универсальный совет — документация предупреждает, что решение зависит от идентификации, аутентификации и архитектуры хранилища, — но как вопрос на обсуждение он стоит того. Если все данные свалены в один контейнер, вы управляете одной большой кучей; если разделены — несколькими, каждая из которых растёт по своим причинам.

Квоты на хранилище — отдельный инструмент, но с оговоркой. Лимит, который никто не обсуждал с людьми, воспринимается как наказание: у человека закончилось место посреди работы, и он идёт жаловаться. Лимит, о котором сказали заранее и который подкреплён понятной инструкцией, где хранить рабочее, воспринимается как правило. Разница не в технике, а в порядке действий.

Где репетировать, чтобы не репетировать на людях

Все описанные выше проверки — «удалил каталог и посмотрел, что будет», «поставил лимит кеша и посмотрел, как ведёт себя программа», «запустил сжатие и прочитал журнал» — разумно выполнять не на рабочем сервере. Нужен отдельный тестовый стенд с копией структуры профиля и парой тестовых учётных записей.

Для такого стенда подойдёт виртуальный сервер: например, VPS MAATRIX с NVMe-дисками, процессорами AMD EPYC и root-доступом. В публичном предложении указаны тарифы от Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) до Djed (16 vCPU, 32 ГБ RAM, 320 ГБ), а между ними Uab, Heka и Maat. Эти ресурсы стоит понимать как отправную точку для проверки, а не как обещание ёмкости: сколько пользователей выдержит конкретная конфигурация, показывает только замер вашей нагрузки. Доступность нужной вам операционной системы и образа проверяйте в форме заказа — она может отличаться по локациям.

Посмотрите на арифметику из нашего учебного примера: пятьдесят профилей по 18 ГБ — это около 900 ГБ. Ни один из перечисленных тарифов не вмещает такой объём целиком, так что тестовый стенд — это не копия продукции, а лаборатория: два-три профиля, на которых вы отрабатываете порядок действий, измеряете прирост и проверяете, что приложения переживают очистку. Для этой цели 80 или 160 ГБ вполне достаточно, а вот под боевое хранилище профилей объёмы считаются отдельно, с запасом на рост и с учётом архитектуры хранения.

Если дальше окажется, что рост связан с тяжёлыми файлами другого рода — например, с большими исследованиями и снимками, — стоит посмотреть, как похожая задача решается в другой отрасли: в статье про архив снимков КТ у стоматолога разбирается вопрос, где держать данные, которые весят гигабайты и не должны жить в пользовательских профилях.

Порядок работы, который не ломает чужую работу

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

1. Измерьте, не удаляя. Составьте таблицу по категориям для нескольких типичных профилей: сколько места, какой тип данных, кто владелец. Это один-два вечера, но после них спор «что можно убрать» превращается в чтение таблицы.
2. Выясните тип хранения. Обычные папки или контейнеры, динамические или фиксированные. От этого зависит, вернётся ли место на диск после удаления данных внутри.
3. Проверьте приложения на тестовой учётной записи. Для каждой программы, чей каталог вы хотите ограничить, убедитесь: что произойдёт после очистки и что программа считает своим кешем.
4. Чистите закрытые профили, в открытых — только штатно. Первые — по таблице решений, вторые — настройками приложений и просьбой к человеку.
5. После очистки контейнеров смотрите журнал сжатия. Если место не вернулось, ответ — в журнале профиля и событиях: сжатие может быть пропущено, а фиксированный VHD так не сжимается вообще.
6. Поменяйте источник роста. Лимиты кешей, перенос рабочих файлов, режим облачных папок, раздельные контейнеры — всё, что снижает ежедневный прирост.

Шаг шестой — единственный, который не повторяется. Остальные нужны, чтобы сделать его безопасно.

Как понять, что получилось

Освобождённые сто гигабайт — приятная цифра, но не результат. Результат — это кривая. Снимите значение занятого места на диске в начале работ, сразу после очистки, и затем через неделю, две и месяц. Если вы вернулись к прежнему наклону — вы убрали следствие. Если наклон стал заметно положе, вы поменяли причину.

В нашем условном примере прирост составлял около 7,5 ГБ в сутки на пятьдесят пользователей. Допустим, лимит кеша браузера, ограничение локальной почты и перенос рабочих файлов из «Загрузок» снижают его втрое — до 2,5 ГБ в сутки. Тогда за месяц набежит около 75 ГБ вместо 225, и очередное окно обслуживания придёт не через две недели, а через несколько месяцев. Цифры, повторим, учебные, но принцип такой: в сумму входят не только удаления, но и то, как быстро диск наполняется после них.

Стоит заодно проверить вещи, которые легко упустить. Не появилась ли жалоба на «пропавшие» настройки — значит, где-то задели больше, чем нужно. Не выросли ли контейнеры на хранилище, хотя внутри места стало больше — значит, не дошло до сжатия. Не появилось ли новое приложение, которое пишет много и быстро, — значит, список владельцев каталогов пора пополнить.

И последнее наблюдение, не технологическое. Профиль на восемнадцать гигабайт при двух гигабайтах работы — не вина сотрудника. Он просто пользуется программами, которые молча копят данные, пока им не скажут остановиться. Остановить их — задача администратора: один раз, понятными лимитами, с заранее проверенным порядком. После этого диск, который вы освободили, остаётся свободным заметно дольше, и еженедельное «найти самую толстую папку» перестаёт быть частью вашей работы.