athacker

Это всё условные обозначение разных частей (или всего целиком) пакетов сетевых протоколов. На разных уровнях протокола (согласно модели OSI) одни и те же (по смыслу) части могут называться по-разному. Где-то -- кадр, где-то -- пакет, где-то -- фрейм. Но это всё условно. Подробности можно почерпнуть в книжке по курсу Cisco ICND1, они там на этом сугубый акцент делают.

Читайте про ScaleMP. Там это можно сделать. Но я бы так делать не рекомендовал.Гораздо проще и дешевле будет сделать прямо на железе RDS-ферму, а брокер будет автоматом юзеров распихивать по конкретными физическим хостам. Либо сделать из этих физических серверов кластер виртуализации, и раздавать юзерам обычные виртуалки в качестве десктопов.

Минусы тонких клиентов начинаются, когда нужно подключать оборудование на местах. USB-принтеры-сканеры-токены-флэшки -- с этим всем серьёзный геморрой. Так что сразу закладывайте в бюджет сетевые МФУ. С флэшками -- более или менее решаемо, у той же ThinStation есть такой функционал. С токенами -- увы, лотерея.

www.inet.no/dante -- socks5-прокси с поддержкой UDP.

Решите вопрос с планировкой и расстановкой оборудования и мебели в квартире, отсюда и пляшите, чего куда разводить. Уголок для роутера (а также в перспективе и коммутатора, а также и NAS, а также, возможно, и видео-регистратора) запланировать стоит адназначна. Я вывел все провода в чулан, и обустроил в углу на стеллаже "серверную стойку". Там стоял ИБП, сервер, гигабитный коммутатор и роутер.

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

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

Кластер из двух серверов не получится. Нужно минимум три -- один из серверов будет общим хранилищем для двух остальных. Это независимо от платформы виртуализации.

Что касается лицензий -- у VMware есть пакеты типа vSphere Essential, они стоят не так дорого, как если брать просто vSphere. Essential Plus покрывает три сервера и один vCenter, стоит около 250-300 тысяч рублей.

Но один сервер под общим хранилищем -- этого мало, так как он становится единой точка отказа (сдохнет -- и полягут ВСЕ виртуалки). Поэтому самым правильным вариантом решения будет конвергентная инфраструктура -- когда сервера виртуализации также презентуют свои локальные диски в какой-то из вариантов software defined storage. Среди вариантов: Ceph (бесплатный, но капризен, и для поддержки нужны нефиговые такие скиллы), VMware vSAN (стоит нефигово) или ScaleIO (тоже стоит порядком, но до 12 Тб сырого места можно юзать совсем бесплатно. В варианте из трёх узлов в кластере ScaleIO 12 Тб сырого места -- это 4 Тб полезного места. При росте числа узлов оверхед будет снижаться. Например, 12 Тб сырого места на 5 серверах уже обеспечит 5 Тб полезного места).

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

Ну и, собственно, игроков на рынке виртуализации не так уж чтобы до фига. Microsoft Hyper-V, VMware ESXi, KVM. Proxmox -- это не вполне система виртуализации, это оркестратор для управления виртуальной инфраструктурой. Непосредственно виртуализацией занимается всё равно KVM (или LXC, но это вам не нужно).

Оратор выше не вполне представляет, как работает современый веб. Помимо IP, версии браузера, версии системы, разрешения экрана и ещё миллиона параметров, которые могут быть сняты через web, есть ещё куки, которые ставятся серверами. Да, каждый из параметров -- это один из миллиона. Но вот их сочетание -- вполне позволяет идентифицировать клиента. А уж установленная кука -- 100% способ.

Так что -- юзайте разные системы, разные браузеры (в инкогнито-режиме или ещё лучше -- в песочнице), и ходите через разные прокси, причём желательно, чтобы прокси ещё и зачищал заголовки HTTP-запросов (такие, например, как X-Forwarded-For или Referer.

Сконвертируйте диски в Xen-формат, насоздавайте виртуалок на Xen и подсуньте им файлы с уже готовыми виртуальными дисками. Диски в разные форматы может конвертить VirtualBox, у него в составе есть утиля. Возможно, что в Xen-формат она тоже умеет конвертировать.

Подсуньте само-сгенерированный сертификат, да посмотрите, что там, в этом трафике :-)

В зависимости от степени упоротости. Если степень велика -- стройте VPN-каналы через интернет "каждый-с-каждым".

Если степень умеренная :-) -- соедините 3 машины между собой VPN-каналами, обозначив их как основные VPN-сервера, а остальные пусть подключаются к двум из трёх этих машин по VPN.

В любом случае, придётся настраивать динамическую маршрутизацию в этих VPN-сетях, через OSPF или iBGP, как будет удобнее. В итоге после отвала любого канала у вас маршрутизация перестроится, и связность останется. Я бы пошёл по второму пути, он проще масштабируется. В первом случае при добавлении нового узла вам придётся руками обходить все остальные узлы и вносить изменения в конфиги.

Совершенно небезопасно. Через iframe делать можно, но аккуратно. Например, обернув его в CSP. Если у вас пользователи заливают видео на какой-то ваш сервер, и потом оно проигрывается оттуда, то CSP поможет. Если же туда можно воткнуть видео с любого источника, то могут быть проблемы в части безопасности.

Да, нормально. Когда стал подробно трекать время, то выяснил, что 5-6 часов в день выходит, при нормальной загрузке. Если получилось 7 или более -- это означало, что я либо задержался на работе, либо фигачил так, что к концу дня глаза на лоб вылезли.

Если два интерфейса, то похоже, что ilO шарит сетевой адаптер с системой. Т. е. у вас 1-ый сетевой адаптер из двух -- работает и на iLO, и на ОС. iLO, если видит в сетевом пакете свой IP, то забирает его себе, до ОС он не долетает.

Пинги на адрес, присвоенный iLO, приходят? Только пинговать и открывать веб-интерфейс iLO надо с других машин, с самого сервера он доступен не будет.

А что там вообще в summary курса? Обо что речь?

А то "протоколы и интерфейсы" -- это больше похоже на API и системные вызовы, а потом вы пишете про "графический интерфейс".