Рубрика: Общее

«Дайте интернет, но чтобы безопасно и что бы было вчера готово!»
В любой компании наступает момент, когда безопасность говорит: «Хватит». Хватит пускать пользователей в интернет с их рабочих станций, где лежит бухгалтерия, документы и доступы к базам.
Задача прилетела мега-классическая: нужно обеспечить доступ к внешним веб-ресурсам для 200 сотрудников, но изолировать этот процесс от внутренней сети. Вариантов было немного:

• Поставить каждому второй ПК (дорого, супер-тупо, стол как и бюджет, не резиновый).
• VDI (VDI на 200 персон ради браузера? Оверкилл).
• Обскурные решения которыми заполнены просторы интернетов.
• Terminal Server (RDS) + RemoteApp. Наш выбор.

Почему «по талонам»? Потому что Chrome — это уже давно не браузер. Это операционная система, которая преиодически показывает сайты. И если дать ей волю на терминальном сервере, она съест всю оперативку, закусит процессором и попросит добавки.

Архитектура: Строим «загон» для Хрома. Мы не стали изобретать велосипед и развернули классическую ферму на базе Windows Server 2022.
Connection Broker: Мозг операции, балансирует нагрузку.
Session Hosts: Рабочие лошадки, где, собственно, и крутится Chrome.
СХД: Профили пользователей (об этом ниже).

Битва за ресурсы: Chrome vs RAM Главный враг терминального сервера — это современный веб. Один открытый YouTube в 4K может положить сессию целого отдела. Что мы сделали, чтобы сервер не умер в первый же день:
GPO для Chrome — наше всё. Мы использовали официальные ADMX-шаблоны от Google.
Отключение аппаратного ускорения. В виртуалке без vGPU оно только мешает, создавая лишнюю нагрузку на CPU.
Блокировщик рекламы (uBlock Origin). Это не вопрос комфорта, это вопрос выживания. Баннеры и трекеры жрут трафик и ресурсы процессора. Мы внедрили расширение принудительно через политики.
Управление вкладками. Расширения типа The Great Suspender помогают выгружать неактивные вкладки из памяти.
Боль с кэшем. Хранить профили локально на хостах в ферме нельзя — юзера каждый раз может кинуть на новый сервер. Roaming Profiles — медленно. Мы остановились FSLogix.

Тут же первая проблема: Кэш Хрома растет бесконечно. За месяц профиль может раздуться до 5–10 ГБ.
Быстрофикс который стал постоянным решением: Настроили политику очистки кэша при выходе или перенаправили папку кэша в temp, который чистится. «Интернет по талонам» не предполагает хранения истории мемов за пять лет.

Безопасность: RemoteApp создает иллюзию, что приложение работает локально. Но мы-то знаем, что юзверь находится внутри сервера. Чтобы любопытные пользователи не начали изучать файловую систему сервера через «Сохранить как…»:

Скрытие дисков: Через GPO скрыли диски C: и D: сервера.
AppLocker: Разрешен запуск только chrome.exe. Даже если они умудрятся скачать «super_game.exe», запустить они его не смогут.
Буфер обмена: Ограничили копирование файлов между сессией и локальным ПК, чтобы исключить утечку документов.

Факапы и выводы Конечно, без приключений не обошлось.

В первый день забыли настроить таймауты, и «висячие» сессии съели все лицензии. Настроили — радуемся.

Кто-то нашел сайт, который майнит крипту в браузере, и один хост ушел в 100% CPU. настроили аллертинг и заодно обновили black-list.

Итог: Ферма живет, 200 пользователей ходят в интернет, внутренняя сеть в безопасности. Нагрузка на техподдержку снизилась: если у юзера «глючит интернет», мы просто сбрасываем его сессию, а не чистим всякое на его компьютере. Хотя все же мне кажется что наиболее лучшим решением мог быть дополнительный слой защиты в виде разнообразные NGFW, HP Wolf Security, RBI и иже с ними, но это уже совсем другая история…

Недавно гиперконвергентные кластеры (ГКС) стали популярны для построения IT-инфраструктуры. Причина в том, что их легко развернуть и можно сэкономить на старте. Но по моему опыту, такой подход не идеален. Хочу объяснить, почему я выбрал классический кластер с внешней системой хранения данных (СХД).

Первое – цена. Сначала ГКС кажется выгодным, особенно для малого и среднего бизнеса с небольшим бюджетом. Развернуть просто, и не нужно покупать отдельную СХД, что экономит время и деньги. Но эта экономия быстро исчезает, когда нужно увеличить кластер, особенно хранилище. Например, чтобы добавить узел, придётся покупать не только диски, но и модули с ресурсами, памятью и лицензиями. Это дорого.

Второй важный момент – производительность гиперконвергентных систем. Сначала ГКС работает быстро, потому что вычислительные мощности и хранилище объединены. Но когда нагрузка растёт, особенно если ресурсы используются для виртуализации и хранения, производительность падает. У меня, когда одновременно выполнялись задачи резервного копирования и миграции виртуальных машин, появились задержки и система работала медленно. С отдельной СХД такого не было.

Что касается отказоустойчивости, то гиперконвергентные системы не сильно лучше классических. Производители обещают надёжность за счёт репликации и распределения данных. Но при поломке узла, восстановление данных и перераспределение нагрузки занимает много времени, и система работает медленнее. В классическом кластере с СХД можно быстро заменить сервер без проблем для инфраструктуры.

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

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

Эта статья – моё личное мнение.

Что же, добро пожаловать. Здесь собраны мои мысли, скрипты, идеи, иногда просто бред. Кстати, тут еще и мое резюме. В остальном же путник, желаю тебе всего наилучшего. Надеюсь что хоть одна моя мысль будет тебе полезна.