Автоматический контроль виртуальных машин

[Hans]

[dupus1]

Мой вопрос был адресован Support, но спасибо за участие в обсуждении, теперь мне ясно, что даже столь простые формулировки можно трактовать иначе

vitaleev, проски - незначащий фактор моих сценариев, все прокси там хорошие и идентичны попарно в п.1 и п.3 как и в п.2 и п.4

Hans, Как я понял - Вы просто запустили вашу старую ферму под новой версией гипервизора, но НЕ получили в распоряжение конкретную сборку, о которой говорит сап и которую я условно обозначил как "VirtualBox 6 JetSwap Super-Puper Edition". Или я не прав?

Еще раз подчеркну, я указываю на то, что использование ЛЮБЫХ виртуальных машин в качестве инструмента, призванного решить задачу множественного серфинга - крайне неэффективно.
Почему и уточняю у Support за качество трафика, его "палевность", верование гугла и т.п.

[Hans]

[Support]

Далее, допустим, запущу виртуалки в режиме immutable. Там будут вписаны прокси и настройки, в процессе работы они, как правило, могут меняться. При перезагрузке ВМ я получу всё обнулённое на момент создания ВМ.

При подготовке системы вы в любом случае вносите все необходимые общие настройки, которые будут действовать для всех клонов. Разумеется, это вносится при обычном режиме работы диска.
Затем диск переключается в immutable и при запуске клона можно выполнять пользовательский скрипт, который внесет индивидуальные изменения, например настройки прокси. Что при перезапуске эти изменения потеряются, проблем тут не вижу, поскольку прокси как правило недолговечны.

Далее, при работе в скрытом режиме в версии VB 6.0.4 есть кнопка Показать. Кнопка нужная, но... виртуалки имеют разные разрешения, и при нажатии на Показать виртуалка раскрывается в текущем разрешении. И если открыть несколько, они очень сильно захламляют стол окнами разных размеров. При работе по RDP окна одинаковые, обозначенные в настройках RDP. И если будет возможность разные разрешения привести к одинаковым размерам, было бы неплохо.

Основная цель - добиться того, чтобы не нужно было смотреть за виртуалками
Поскольку виртуалки все одинаковые, я вообще не вижу большого смысла наблюдать за конкретным экземпляром, поскольку отличий будет ноль.
Если экземпляр ведет себя неадекватно, его можно просто перезагрузить для сброса всех изменений (при применении immutable).
Конкретные критерии неадекватности тоже можно определить, при которых будет следовать перезагрузка.

И ещё одно, при запуске в VB 6.0.4 не подхватили прокси примерно 30% виртуалок. С чем это связано, пока не разобрался.

Они использовали основной IP или вообще не получили доступ в сеть?

абываем напрочь про существование виртуальных машин и:
1. запускаем сейфсёрф на реальном компьютере через прокси - этот вариант «палится»?
2. на этом же компьютере запускаем параллельно сейфсёрф2 через прокси2 - эта или работающая копия из п.1 теперь «палится»?

Если мы считаем, что сам по себе прокси не палится, то получаем две копии с одинаковым отпечатком реального компьютера, отличающиеся только IP-адресом. Поскольку на двух копиях никто не остановится, а запустят столько, сколько вытянет компьютер, то получаем штук 200 абсолютно одинаковых компьютеров, отличающихся только IP-адресами, которые будут палиться
Если предположить, что таких компьютеров у нас несколько, то на 1000 посещений мы получим посещения всего с 5 разных компьютеров, что тоже легко определяется.
Плюс даже если удастся закрыть все способы утечки данных между двумя экземплярами программ на одном компьютере, то не факт, что не появятся новые и внезапно всех не забанят.
И по-хорошему, либо мы должны использовать все прокси строго из одного часового пояса, либо это тоже будет палиться, поскольку на отличие часового пояса на компьютере от часового пояса, определяемого по геолокации, тоже обращают внимание.

Всё закрываем и вспоминаем про VirtualBox 6 JetSwap Super-Puper Edition:
3. запускаем эту виртуальную машину через прокси - это «палится»?
4. параллельно запускаем копию/клон/снимок этой же виртуальной машины через прокси2 - эта или работающая копия из п.3 теперь «палится»?

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

[dupus1]

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

Спасибо, теперь ясно, что секрет успеха в том, что клоны - вовсе не клоны

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

Справедливо, но часовой пояс, это всего лишь параметр в реестре или переменная в памяти движка.

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

В таком случае, просьба - сделайте вывод информации о палевности на панели сейфсёрф и\либо в списке сессий, это будет мотивировать либо к переходу на фирменную систему контроля, либо на поиск альтернативных контр-палевных решений

[Hans]

И ещё одно, при запуске в VB 6.0.4 не подхватили прокси примерно 30% виртуалок. С чем это связано, пока не разобрался.

Они использовали основной IP или вообще не получили доступ в сеть?

Здесь я ничего не менял, просто переустановил v4 на v6. При этом Список активных уменьшился и держался стабильно длительное время в пределах, как уже говорил, на 30% меньше, чем изначально. Естественно дал время, чтоб все виртуалки после запуска подхватились и стабилизировались и список не изменялся на увеличение, на это обычно часа 2 уходит. Виртуалки я не проверял, так как занимался подгонкой старых скриптов к новой версии, работал только с одной тестируемой машиной. Убедился, что новая версия в принципе рабочая, только жрёт оперативки на 2 Гб больше. Затем снова переустановился на v4, и пропавшие 30% сразу нашлись и подхватились. Я думаю, сама версия 6.0.4 блокирует и не пускает некоторые адреса только по ей одной известному принципу, а что может быть иначе? Я как-то упоминал на форуме месяц-два назад, что некоторые прокси при отличных показателях и скоростях не пускают SafeSurf в работу, особенно при перезагрузках системы, до перезагрузки они работали без проблем. Не пускали они и через 10 часов и через 20. Заменой прокси проблема решалась мгновенно. Скорей всего, это и есть палево. Не думаю, что эта ситуация замешана в новой версии VB, иначе как объяснить, что пропажа появилась при возвращении на старую версию? Все прокси остались те же самые

[moneymaker3]

Если я правильно понял проект будет базироваться на открытых исходниках Vektora? Которые он собирается выложить или уже это сделал. В действительности победил гугл и все их фродсистемы, возможно на какой-то период времени. Системы виртуализации которые можно будет применять - это VirtualBox? С другими системами виртуализации проект не актуален? Лично я применяю Vmware 6.7 версии - базового функционала ESXi 6.5-6.7 free лицензии достаточно, если активировать ключами с торрентов, можно объединить все в единую систему 2-3к гостевых клонов.

Основное узкое место это однозначно дисковое пространство SSD диска, в нынешних реалиях замена или добавление дисков стоит под сомнениями большими, и не хотелось вкладывать средства в них. Я в доскональности не знаю схему работы линк клонов VirtualBox, но в vmware она работает следующим образом у меня.

Гостевая система имеет 3 диска,

1 диск 3Gb (тонкий) -на нем операционная система(защищен от изменений после настройки OS),
2 диск 300 Mb (тонкий) - SafeSurf (запись изменений разрешена, все обновления устанавливаются)
3 диск 1,5 Gb (тонкий) - файл подкачки, при этом диск при выключенной машине имеет размер несколько килобайт, при включении создается файл подкачки.

При такой конфигурации максимально плотно и эффективно используется диск, до 100 виртуальных машин помещаются на диске 120 Gb. При этом они не испытывают не хватки дискового пространства даже при создании линк клона диски не разрастаются. А при достижении критической точки, раз в пару месяцев делается перезагрузка сервера для высвобождения места.
Все виртуалки имеют подключение к сети сетевой мост - дает возможность маневрировать и управлять сетью.
Для проксирования трафика используется proxycap - есть возможность настройки путем генерации файла конфигурации и перезапуска сервиса. Лучшим решением конечно было бы встраивание проксирования в движок браузера и поддержкой HTTP(S), SOCKS5 прокси. Так исключаем стороннего разработчика и повышаем стабильность.
Sandboxie - он не нужен совершенно статичные диски исключают проблемы с вирусами, перезапуск виртуалки чистит систему.

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

Хостовая ОС - для меня в любом случае нужны будут серверные Windows 2012-2016. 4 сокетные платформы с большим объемом памяти 512 Гб и более дают возможность работы только эти OS. Как работает VirtualBox на Linux понятия не имею.
Хочу поучаствовать в тестах системы одним или несколькими серверами.

[loller5]

Если я правильно понял проект будет базироваться на открытых исходниках Vektora?

Самая быстрая рука на всём Диком Западе? Оперативненько

[zl0y]

VirtualBox приятен только тыкательным интерфейсом и все

Я использую KVM (qemu) виртуализацию (большинство хостеров только ее и используют)
- нет проблем с размером образа и нагрузкой на HDD, т.к. один мастер образ (2 Г) для всех виртуалок (подойдет любой HDD)
- самое эффективное использования ОЗУ (KSM) - 500МБ * 200шт = всего 35Гб
- шустрые virtio паравиртуализированые драйвера

для инф.: все экземпляры виртуалок седят за NAТ, один кэширующий DNS сервер (undbound), для отличая экземпляров друг от друга присваиваю уникальные MAC адреса

[Hans]