Вди Скала-Р Врм. Что Это Такое И Откуда Оно Взялось

Цель статьи — рассказать о продукте и его архитектуре.

По сути то, что наши технические предпродажные инженеры постоянно говорят нашим партнерам и клиентам.

Мы оставляем себе немного, как помидоры для наших «конкурентов», совсем немного.

Где бы мы были без этого :D Спойлер: кроме этого предложения в статье о вирусе ничего нет.

Немного о команде

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

Собственно, так и была создана линия продукции, в названии которой присутствует слово «Рок».

Сегодня речь пойдет о программном продукте — решении VDI (инфраструктура виртуальных рабочих столов) Scala-R Virtual Workplace. Сокращенно Scala-R VRM.

Почему мы решили использовать VDI?

Мы верим в эту технологию.

У нас есть опыт как внедрения VDI, так и участия в его развитии.

Проекты внедрения VDI не так просты, поскольку влияют на работу многих пользователей.

Но нам кажется, что время VDI пришло.

Мы видим спрос на подобные решения на российском рынке.

Многие заказчики начали учитывать санкционные риски, у некоторых даже есть KPI по импортозамещению.

Ряд организаций уже давно активно используют подобные продукты западных производителей (наиболее популярные — Citrix и VMware).

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

Ээкскурс в историю Наша команда уже не первый раз занимается разработкой VDI-решения.

Вместе с коллегами из Virtuozzo (подразделение Parallels, занимающееся виртуализацией) мы в течение 4 лет совместно разрабатывали продукт для виртуализации десктопов — Parallels VDI. В рамках этого сотрудничества наша команда занималась формированием технических и бизнес-требований к продукту.

Наш партнер превратил требования в код. Особенностью этого продукта стало использование виртуализации контейнеров Windows, разработанной Parallels. В то время Microsoft даже не думала о собственных контейнерах.

У продукта были свои преимущества, но были и технические сложности (в том числе из-за тары).

В конечном итоге мы сертифицировали FTSЭK Parallels VDI и Virtuozzo Containers для Windows. Провел несколько внедрений.

К сожалению, по ряду причин продукт прекратил свое существование.

Права на код остались за партнером, поэтому мы не имели права самостоятельно развивать продукт. Однако интерес к отечественному VDI сохранился.

Помимо совместной разработки Parallels VDI, мы имеем большой опыт реализации проектов консолидации десктопов с использованием решений Citrix и VMware. В общем, наша команда увидела, пожалуй, всё, что происходит «под капотом» VDI-решений.

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

Закидаем помидорами отечественные VDI-решения Всем известно, как быстро в нашей стране развиваются отечественные open source решения.

Возможно, в этом нет ничего страшного, но наш опыт показал, что на рынке часто подменяют понятия.

Системой VDI можно назвать продукт, в котором все делается «вручную»: администратор создает виртуальную машину (ВМ), администратор передает пользователю IP-адрес, пользователь по протоколу подключается по инструкции к конкретной ВМ.

.

Нет даже минимальной автоматизации жизненного цикла ВМ.

Да, для небольших организаций этого может быть достаточно.

Но назвать это промышленным VDI-решением совершенно невозможно! Наблюдая такое безобразие, мы попытались сформулировать гигиенические минимальные функции промышленного решения VDI .

Что, кстати, тоже помогло нам в разработке Scala-R VRM. Надо признать, что не все собирают что-либо из открытого кода на коленях.

Мы видели товарищей, которые, не раздумывая, предлагали использовать в государственных организациях Испанский VDI , который может интегрироваться с OpenNebula. Честно говоря, мы не знаем, насколько он хорош.

Но то, что его нет в реестре отечественного ПО - это факт. Есть интерес к отечественному VDI. Еще есть предложение, хотя по опыту многих отечественных разработчиков все работает только на слайдах PowerPoint. Очевидный вывод – нужно создать свой хороший промышленный VDI, который будет максимально приближен к мировым лидерам в этой области.

Кроме того, к моменту принятия решения мы уже разрабатывали собственную систему управления виртуализацией Scala-R Management. Так что создание собственного VDI с собственной системой управления виртуализацией — логичное и очевидное решение.

Итак, в конце 2016 года мы усилили команду и начали собственную разработку с нуля.

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

Поэтому мы побежали быстро.

Что такое Scala-R VRM

Общая информация Цель:

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

Подключиться к ним можно с устройства защищенного доступа под управлением отечественной ОС.

Целевыми потребителями являются средние и крупные промышленные предприятия, государственные и коммерческие организации, госкорпорации, региональные и федеральные ведомства и органы власти.

Архитектура

Тем, кто не читал, рекомендую прочитать раздел «Шаги по подключению пользователя к виртуальному рабочему столу».

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

В этой статье мы подробнее рассмотрим основные функции компонентов Scala-R VRM. Схему можно увидеть в самом начале статьи.

Компоненты будем рассматривать слева направо.

Но сначала стоит поговорить о функции, которая есть у всех компонентов нашего VDI-решения — контроль целостности.

Как во время запуска компонента, так и систематически проверяется его целостность (время проверки можно настроить).

Если целостность нарушена, компонент перестанет работать.

VRM-клиент — клиентское программное обеспечение, установленное на устройстве доступа пользователя.

Предоставляет графический интерфейс для конечного пользователя для взаимодействия с инфраструктурой VDI. На момент написания VRM Client доступен для следующих операционных систем (список обновляется в зависимости от потребностей партнеров и клиентов):

• KasperskyOS для тонкого клиента;
• Альто 7 СПТ, Альто 8 СП, Альто 8;
• Астра Линукс Смоленск, Астра Линукс Орел;
• GM-Box;
• Windows 7 и выше.

• Формирование аппаратного идентификатора (HWID) для авторизации устройства доступа.

  При запуске Клиент собирает информацию об устройстве, на котором он запущен.

  HWID генерируется на основе неизменяемых параметров оборудования.

  При подключении к Connection Manager происходит авторизация устройства доступа: BPM Client передает HWID и информацию об устройстве, Broker Manager авторизует устройство согласно настроенной политике.

• Взаимодействие со смарт-картой при авторизации с использованием сертификата.

  Если настроена аутентификация по сертификату или двухфакторная аутентификация, клиент BPM «общается» со смарт-картой напрямую, используя библиотеку производителя смарт-карты.

  На данный момент поддерживаются все устройства, широко используемые в России.

• Изменение пароля пользователя.

  Если при авторизации окажется, что срок действия пароля пользователя истек, BPM Client отображает экран смены пароля.

  Важная функция для пользователей, чей VDI является единственным окном в корпоративную сеть.

• Настройка и запуск протокола доставки на рабочий стол.

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

  Когда приходит время подключения к виртуальному рабочему столу, VRM Client генерирует параметры запуска для используемого протокола и запускает его.

• Дополнительное шифрование трафика диспетчера подключений.

  Более того, защищены как управляющий трафик, так и трафик протокола доставки рабочего стола (в дополнение к защите самого протокола).

  Эта функция не сертифицирована ФСБ.

  Поэтому, если задача сертификация, требуется дополнительное сертифицированное средство защиты канала от BPM Client до Connection Manager. В этом случае встроенную защиту можно отключить.

Набор сервисов, которые будут работать, зависит от возможностей этого протокола (переадресация принтеров, общий буфер обмена, смарт-карты и т. д.).

И как они будут работать.

У нас пока нет собственного протокола доставки на рабочий стол.

Поэтому мы оказываем поддержку существующим.

Мы используем разные протоколы для подключения к виртуальным рабочим столам с разными операционными системами:

• VRM в Linux — RX@Etersoft ,
• BPM в Windows — RDP.

В этом случае смарт-карта видна как в устройстве доступа, так и на виртуальном рабочем столе.

А это важно, если используются защищенные тонкие клиенты, в ОС которых авторизация пользователя также осуществляется с помощью сертификата со смарт-карты.

Если смарт-карта не видна локально, устройство будет заблокировано.

Нас часто спрашивают, почему мы не используем SPICE. Есть несколько причин:

• SPICE не поддерживает сквозную авторизацию от клиента VDI к виртуальному рабочему столу.

• SPICE перенаправляет все устройства как сырые USB. Те.

  Сетевой трафик с устройством, который передается по каналу USB, начинает передаваться по сети на виртуальный рабочий стол и обратно.

  Это приводит к увеличению трафика и отсутствию проброшенных устройств в ОС устройства доступа.

  Эта технология, кстати, не позволяет пробрасывать сетевые принтеры, настроенные на устройстве доступа.

• Смарт-карты также пересылаются как необработанные USB-устройства.

  В результате они не будут видны локально на устройстве доступа.

  Это не будет работать на защищенных устройствах с авторизацией по сертификату.

Протокол настраивается не только для BPM-клиентов на устройстве доступа, но и на виртуальном рабочем столе с помощью нашего BPM-агента, до которого мы скоро доберемся.

Менеджер подключений — компонент, завершающий соединения пользователей.

Это прокси-сервер, который перенаправляет управляющий трафик менеджерам брокеров и трафик протокола доставки рабочего стола на виртуальный рабочий стол.

Его следует разместить в демилитаризованной зоне как пограничный компонент. Диспетчеры соединений настраивают одну из четырех политик аутентификации:

• пара логин-пароль;
• по сертификату;
• двухфакторная аутентификация;
• или логин-пароль, или сертификат.

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

Обычно это не требуется, и для всех настраивается одна политика.

Отказоустойчивость диспетчеров соединений реализована очень просто.

Клиент BRM содержит их список.

BPM-клиент подключается к первому из списка, при сбое — ко второму и т.д. Возникает закономерный вопрос: как осуществляется балансировка пользователей между диспетчерами соединений, если пользователей десятки тысяч? В планах на разработку собственный балансировщик, поэтому пока используем сторонний, который объединяет соединения пользователей с разными менеджерами подключений.

А чтобы это можно было сделать более эффективно, через API можно получить текущий коэффициент загрузки Диспетчера соединений по шкале от 0 до 1. Опыт показал, что один диспетчер соединений может обрабатывать около 2000 пользовательских сеансов.

Если установка рассчитана на несколько большее количество пользователей, можно административно указать Менеджеры соединений в конфиге BPM Client для некоторых пользователей в одном порядке, а для другой части пользователей в другом порядке.

Брокер-менеджер — это мозг Scala-R VRM. Большая часть функциональности основана на этом компоненте.

Боюсь, мы не будем здесь все описывать.

Попробуем выделить главное:

• авторизация устройств доступа.

  После получения диспетчера подключений HWID от клиента диспетчер брокера проверяет, разрешено ли устройству подключение.

  Для неизвестных устройств доступа есть выбор из двух политик – разрешить подключение или запретить.

  Если настроен запрет, устройство доступа будет занесено в базу данных, после чего администратор должен вручную разрешить подключение с этого устройства.

  Администратор также может запретить подключение с определенного устройства.

  Либо система может временно заблокировать его из-за неудачных попыток авторизации пользователей (если они попытаются угадать логин и пароль).

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

• работа с внешним каталогом LDAP. Чтение из LDAP при: назначении пользователей и их групп на рабочие столы; формирование списка доступных рабочих столов (проверяется членство в группе).

  Пользователь авторизуется и обрабатывается результат авторизации.

  Изменение пароля пользователя в LDAP (фактически AD или комбинации LDAP/Kerberos).

• соблюдение политики паролей пользователя.

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

  В этом случае срабатывает более строго настроенная политика.

  Если это политика Scala-R VRM, то пользователь будет заблокирован из-за неудачной попытки авторизации только в нашей системе, а администратор сможет разблокировать его вручную, не обращаясь к каталогу LDAP. Если политика LDAP сработала, вам придется разблокировать пользователя там.

• взаимодействие с системой управления виртуализацией Scala-R Management. Scala-R VRM ничего не знает об оборудовании, на котором работают виртуальные рабочие столы.

  Система использует API управления Scala-R. Объединяющим объектом этих систем является пул ресурсов — логический сегмент ресурсов, внутри которого распределяются ЦП, ОЗУ и емкость диска.

  Пулы настольных компьютеров находятся внутри этих объектов — пулов ресурсов; Кстати, уже в летнем релизе мы интегрируем интеграцию с VMware и OpenStack в Scala-R Management, что позволит нам использовать наш VDI совместно с этими системами виртуализации.

• автоматизация жизненного цикла виртуальных рабочих столов.

  Эта часть будет рассмотрена отдельно ниже.

• выполнение управляющих действий администратора.

  Возможности администратора достаточно широки.

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

  И это далеко не полный список возможностей.

ЛДАП комментарии не требуются.

В каждой организации есть каталог LDAP как централизованная система управления учетными записями пользователей.

Мы поддерживаем интеграцию с реализациями Microsoft Active Directory и Linux LDAP/Kerberos. PostgreSQL — конфигурационная база данных для хранения системных данных.

Вы можете использовать российскую СУБД Postres Pro, даже сертифицированную.

Однако ванили обычно достаточно.

Агент ВРМ — это ключевой компонент для управления и подготовки виртуального рабочего стола.

Он устанавливается на этапе подготовки шаблона, после чего его можно обновить из веб-панели администратора.

На наш взгляд, этот компонент критически необходим для автоматизации подготовки рабочего стола.

Без него просто невозможно обеспечить адекватное управление рабочим столом (вход в домен, настройку фаервола, настройку разрешений на проброс устройств и т.п.

).

А если управление осуществляется вручную, без агента, то такое решение нельзя назвать VDI. Поэтому наличие этого «посланного казака» обычно отличает промышленное VDI-решение от «ручного привода» ручной сборки.

Функции, выполняемые Агентом BRM:

• Указание имени хоста.

  Виртуальным рабочим столам присваиваются имена автоматически по маске, заданной администратором.

  Помимо имени виртуальной машины, Агент настраивает ее имя хоста с таким же именем.

• Добавление виртуального рабочего стола в домен (включая рабочие столы Linux) или настройка авторизации LDAP/Kerberos. При использовании Active Directory администратор может указать конкретное организационное подразделение, в которое будут добавлены учетные записи виртуальных рабочих столов.

• Подготовка к подключению пользователя.

  Перед каждым подключением Агент VRM получает от менеджера брокера команду на подготовку виртуального рабочего стола, которая включает в себя:

  • настройка серверной части протокола доставки виртуальных рабочих столов по политикам, полученным от брокера-менеджера (например, если перенаправление локальных папок запрещено администратором, то, как бы пользователь ни старался, это не сработает, поскольку отключен на серверной стороне протокола);
  • добавление пользователя в локальную группу – для Windows это могут быть «пользователи удаленного рабочего стола» (локальный пользователь) или администратор, для Linux существует специальная группа для протокола RX;
  • Конфигурация брандмауэра.

    Агент BPM открывает определенный порт в брандмауэре для получения соединения от диспетчера соединений.

• Выполнение команд менеджера брокера.

  Например, при инициализации подключения к сеансу пользователя BPM Agent показывает пользователю окно с запросом разрешения на подключение и запускает VNC-сервер, к которому администратор подключается из веб-консоли; В конце сеанса VNC сервер отключается.

  Или отобразить сообщение, отправленное администратором.

• Обновление Агента BRM до новой версии.

  Если установочная версия была обновлена, но Агент остался на старой, у администратора будет индикация об этом в веб-интерфейсе.

  Обновление агента можно запустить из веб-консоли управления.

Наша система управления платформой виртуализации.

На рисунке компонент показан монолитно, т.к.

основное внимание в этой статье уделяется системе VDI. По сути, есть еще отказоустойчивость, масштабируемость и балансировка нагрузки.

В этой статье мы не будем подробно рассматривать возможности данного продукта.

Если вам интересно, на что он способен, напишите в комментариях и мы подготовим отдельную статью.

Агент Скала-Р Контроль .

Компонент на узле виртуализации, который передает команды управления Scala-R гипервизору и собирает данные с узла.

Подробности в отдельной статье, если будет интерес.

Автоматизация жизненного цикла виртуальных рабочих столов

Пулы настольных компьютеров необходимы для сопоставления размещения виртуальных машин с пулом ресурсов системы управления виртуализацией.

Существует несколько типов пулов рабочих столов:

• персонализированный,
• полуавтоматический,
• сессионный.

Персонализированный пул настольных компьютеров

Вариант использования: настольные компьютеры для руководства или сотрудников с весьма специфическим набором программного обеспечения.

Давайте посмотрим на настройки персонализированного пула:



Как видите, в настройках нельзя даже задать шаблон рабочего стола.

Это связано с тем, что каждый рабочий стол создается администратором отдельно.

Среди параметров, заслуживающих особого внимания:

• таймаут неактивности — время бездействия пользователя внутри виртуального рабочего стола, по истечении которого пользователь будет отключен от рабочего стола и выйдет из VRM Client;
• таймаут выключения – отсчитывается с момента отключения пользователя от виртуального рабочего стола (самостоятельно или по таймауту неактивности).

  По истечении времени ожидания выключения рабочий стол выключается.

  Если значение равно нулю, тайм-аут отключен;

• Сервисы – набор зависит от выбранного «протокола».

  Мы описали, как эти параметры используются в Агент ВРМ .

Персонализированные рабочие столы назначаются конкретным учетным записям пользователей.

Персонализированное (автоматическое) объединение рабочих столов

Чтобы я мог из одного шаблона создать один для всех, и все.

Лень, знаете ли, — двигатель прогресса.

Вариант использования: набор персонализированных рабочих столов с одинаковым программным обеспечением.

Настройки бассейна:



Здесь уже есть больше настроек.

Рассмотрим отличительные параметры:

• маска именования – при автоматическом создании мы называем рабочие столы по маске;
• максимальное количество — верхний предел количества рабочих столов в пуле;
• минимальное количество — сколько виртуальных рабочих столов будет поддерживать система, созданных в пуле.

  Если администратор удалит рабочие столы, система автоматически создаст новые до «минимального количества»;

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

Всё, рабочий стол, за которым закреплен пользователь, стал персонализированным.

Учетная запись пользователя тесно связана с определенной таблицей, пока администратор не разделит их.

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

В этом случае система автоматически создаст виртуальный рабочий стол для конкретного пользователя.

Так пока не достигнем «максимального количества».

Сессионный пул рабочих столов

Сценарии использования: типичные стандартизированные рабочие столы пользователей; географическое распределение пользователей по часовым поясам и меняющиеся графики пользователей.

Настройки бассейна:



Рассмотрим отличительные параметры:

• Режим создания — выберите один из:
  • полные клоны – соответственно, каждый рабочий стол является полноценной виртуальной машиной;
  • связанные клоны — Linked Clones в известной терминологии.

    Используемая платформа виртуализации позволяет использовать эту технологию, но она реализована не так, как VMware. Существуют ограничения, которые мы обошли, реализовав хорошую программную логику.

• горячий резерв — количество свободных рабочих столов, которые система поддерживает в состоянии готовности к подключению.

  Параметр необходим для минимизации времени ожидания пользователя.

  Важно отметить, что частью горячего резерва считаются десктопы из «минимального количества», еще не занятые пользователями.

  Эти два параметра позволяют, например, сразу создать 50 рабочих столов для отдела в 50 сотрудников и указать «горячий резерв», например, 10. Тогда, подключив 41 сотрудника, система создаст 51 рабочий стол (чтобы было 10 в горячем резерве).

  Таким образом вы сможете обезопасить себя от изменения количества одновременно работающих сотрудников в том или ином отделе;

• действие при завершении сеанса — если включен таймаут неактивности, становится доступным:
  • выключение — по существу оставляет рабочий стол зарезервированным для пользователей и только отключает его.

    Однако по-прежнему существуют инструменты, уникальные для пула сеансов, такие как воссоздание всех рабочих столов из нового шаблона;

  • удаление – после того, как пользователь поработал, мы удаляем его рабочий стол; система создает новые на основе настроенного «минимального количества» и «горячего резерва»;
  • перевод в «горячий резерв» — регистрация пользователя с рабочего стола снова считается частью «горячего резерва».

    Следующий пользователь, который подключится, может быть назначен этому рабочему столу.

Срочная задача, которая позволит сэкономить аппаратные ресурсы для крупных распределенных организаций или сменного графика работы.

Как отделить пользователей от рабочих столов

любое подключение должно контролироваться системой.

Нехорошо, если после первого подключения пользователь сможет запустить протокол доставки рабочего стола и подключиться к подсмотренному IP-адресу.

В системе VDI не останется логов о его подключении.

В целом мировые лидеры в области VDI не стали бы создавать различные Security Getways по периметру сети в DMZ. Мы уважаем опыт мировых лидеров, поэтому сделали таким же и наш Connection Manager. Менеджер соединений, как часть серверной составляющей решения VDI, устанавливается в демилитаризованной зоне и обеспечивает подключение пользователей к инфраструктуре VDI. Пользователь не имеет прямого сетевого доступа к виртуальным рабочим столам, менеджеру брокера или кому-либо еще.

В качестве следующего шага необходимо исключить возможность подключения к соседнему рабочему столу: пользователь легитимно подключается к своему рабочему столу, смотрит свой IP-адрес и перебором пытается подключиться к соседнему рабочему столу в этой сети.

Здесь на помощь приходит BPM Agent, открывающий необходимый порт в закрытом брандмауэре, чтобы пользователь мог подключиться через Connection Manager. Все остальное закрыто.

В конце сеанса порт закрывается.

В результате подключиться нелегитимным способом не получится, только после авторизации в системе.

А если есть авторизация, значит, мы уже зарегистрировали устройство, с которого подключались, пользователя и рабочий стол, к которому подключались.

В случае инцидента сотрудники ИБ скажут нам спасибо.

Кстати, мы можем отправлять системные логи напрямую через syslog в такие системы, как SIEM.

P.S.

Далее мы просим всех прокомментировать.

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

Теги: #Виртуализация #ИТ-инфраструктура #Системное администрирование #vdi #корпоративные системы #корпоративные приложения #IBS

• Rutracker Попросил Пользователей Решить Судьбу Проекта

  19 Oct, 24

• Рейтинг: 20 Европейских Городов С Наибольшей Долей Миллионеров Среди Населения

  19 Oct, 24

• Codefest 2018: Мы Набираем Таланты

  19 Oct, 24

• Я Из Морейниса. Косые Взгляды Или Уважение?

  19 Oct, 24

• Список Все В Календаре Google

  19 Oct, 24

• Как Работает Массив В Swift

  19 Oct, 24

• Подводные Камни Выбора Дата-Центра

  19 Oct, 24

• Как Искусственный Интеллект И Машинное Обучение Помогают Сотрудникам Повышать Свои Навыки

  19 Oct, 24

• Терминология Google Analytics И Яндекс.метрики: Как Не Запутаться Во Всех Этих Данных

  19 Oct, 24

• Дети И Компьютер

  19 Oct, 24