sbh: За компом может не быть ни движения курсора, ни нажатий клавиш. Но комп может делать какой-нибудь сложный расчёт или моделирование графики или, например, антивирус в фоне будет ковыряться в файлах. Это всё тоже бездействие?
Azure SQL -- ну, просто облачная база данных :-) Аналогом является тот же Amazon RDS. Только в Azure это, условно говоря, на базе MS SQL, а у Амазона на базе других движков.
Как переместить -- ну, спланировать и переместить :-) Про синхронизацию Azure AD с локальной есть выше, про миграцию БД в Azure SQL можно почитать, например, тут: https://azure.microsoft.com/ru-ru/documentation/ar...
Alexander Tartmin: А, ну и да. Хотя оратор выше и написал ересь, но отчасти он прав -- если у вас есть своё нормальное оборудование -- ну перенесите его туда, где нет проблем со связью и электричеством, и запилите всю виртуализацию на своём оборудовании. Всё равно даже в облаке нужно будет настраивать всё на серых IP-адресах, от греха, и делать дырочку в виде VPN-сервера в облаке для подключений извне.
Alexander Tartmin: Товарищ. Вы спросили, цитирую: "Как перенести доменную сеть в облако Azure"?. Вы не спрашивали про наличие преимуществ в Azure перед другими платформами виртуализации.
Домен в Azure развернуть можно. Ровно также, как и на любой другой облачной платформе -- поднять виртуалку, установить на ней Windows Server и поднять на нём домен.
Office365 -- это вообще про другое. Это набор офисных приложений на вебе.
Я только не очень понимаю, зачем вам на одной физической площадке контроллер домена и там же виртуальный RODC :-) В удалённом офисе -- ещё понятно, зачем RODC, а локально зачем?
А в остальном -- да, вы правы, точно также можно домен и на амазоне развернуть. Поэтому разворачивать лучше там, где дешевле и что лучше знакомо.
Вячеслав Беляев: Сделайте доступ сотрудников к серверу по RDP. RDP потребляет копейки, пара сотен килобит трафика на одну сессию ему более чем достаточно.
xsash: Хинт -- второй сервер вовсе не обязательно должен быть мощным, и не обязательно должен быть у Hetzner. У вас же есть домен в офисе? Пользуйте свой контроллер домена.
Если своего нет -- можно развернуть, в офисе или у любого хостера взять виртуалку, и там поднять контроллер домена, а сервер у Hetzner и контроллер соедините по VPN.
dredd_red: вы что-то не так сделали. По предложенной мною схеме ответ будет с самого что ни на есть правильного IP.
Схема такая: у вас есть "open server", у него есть IP в локальной сети, скажем, 192.168.0.1. Есть ваша рабочая машина, на которой вы запускаете программу. Допусти, IP этой машины 192.168.0.2. Есть некий IP в интернете, на который программа ломится и проверяет ключ. Допустим, этот IP -- 1.2.3.4. Тогда нужно присвоить этот IP вашему "open server", в дополнение к тому, который уже там есть (192.168.0.1), а на рабочей машине сделать так:
route add 1.2.3.4 192.168.0.1
Тогда на адрес 1.2.3.4 ваша машина будет ходить не в интернет, а через шлюз 192.168.0.1 пинать второй IP вашего "open server" (1.2.3.4)
Кирилл: Сквид может работать как прозрачный прокси, но вариантов резать скорость NAT'ом на основе логина в AD в природе не существует, и технически существовать не может. Отчасти потому, что NAT не занимается ограничением скорости, от слова "вообще", этим занимаются более другие предметы. Но в основном потому, что сущности, которыми оперирует NAT -- это IP-адреса, и AD с его юзерами и группами к NAT'у тупо некуда прикрутить.
Но если вам хочется именно файрволом резать скорость, то могу предложить разнообразные костыли. Например, можно раздавать пользователям в офисе интернет по VPN. Кто хочет выйти за пределы локалки -- подключается по VPN к некоему серверу, получает фиксированный, принадлежащий именно этому пользователю IP-адрес в туннеле и шлюз по умолчанию., И ходит с этого IP в интернет. А вы файрволом уже соответствующие IP разделяете по скорости, как требуется. Ну то есть, полностью та же схема, которой пользуются многие интернет-провайдеры.
Второй костыль -- скриптом детектить IP-адреса машин для залогиненых пользователей. Это криво и не гарантирует однозначного соответствия между параметрами "Залогиненый пользователь" <--> "IP компьютера, на котором он залогинился" (как, например, обрабатывать ситуацию, когда пользователь залогинился более чем на одном компе одновременно?), но в целом, работать будет.
Третий костыль -- жёстко прибить IP-адреса к рабочим станциям соответствующих пользователей. Т.е. мы знаем, что юзер vasya работает с машиной vasya-pc, и у этой машины IP всегда должен быть 192.168.0.1. Руками адреса выставлять на рабочих станциях, или в DHCP прописывать статически соответствие MAC и IP -- это как угодно.
Но всё вышеперечисленное -- реально костыли (ну может, кроме VPN), а в целом, не очень понятно, почему вы при наличии AD не хотите использовать Squid. Когда есть AD -- сквиду не нужен режим прозрачного прокси (тем более, что HTTPS в общем случае проксироваться в этом режиме не будет). Настройте прокси, раздайте групповыми политиками всем клиентам IP и порт прокси-сервера, и у вас всё будет работать -- браузеры будут авторизоваться через NTLM автоматически, а сквид будет регулировать скорость. Торренты так не урезать, понятное дело, но это ж конторская сеть, как я понимаю, так что нефиг на работе торренты качать :-)
Azazel PW: Коллега, почитайте по BGP. Хотя бы статью из серии "Сети для самых маленьких". BGP бывает двух видов -- IBGP и EBGP. IBGP, как следует из названия, (Internal BGP) используется для маршрутизации ВНУТРИ AS. Внутри своей сети через все VPN-туннели вы можете использовать любой номер AS. Также существуют так называемые "серые AS", их назначение такое же, как и серых IP -- для использования внутри локальной сети.
Регистрация AS не нужна для этой задачи, от слова "ВООБЩЕ".
Кроме того, BGP -- не единственный протокол динамической маршрутизации. Есть ещё OSPF, например, и тоже вполне пригоден для использования в локальной сети.
Azazel PW: Вы же не думаете, что интернет-провайдеры дурачки, когда делают резервирование линков с помощью динамической маршрутизации, а не на скриптах? :-) Скрипт будет отрабатывать дольше, чем динамическая маршутизация. Переключение маршрутов в каком-нибудь BGP займёт считанные секунды, а скрипт будет запускаться раз в несколько минут. Ну это как минимум, не касаясь других профитов динамической маршрутизации.
Респект за терпение :-) Картинка красивая, но к сожалению, малоинформативная. Я имел в виду какую-то подобную картинку: bit.ly/1JABOMu
Помещения и кросс-панели не важны, важны только соединения между устройствами -- компами, коммутаторами, роутерами.
В любом случае, судя по симптомам, у вас реально кольцо образуется -- где-то у вас неучётнная связь между коммутаторами появилась. Поэтому предыдущий мой совет всё равно остаётся в силе -- разобрать все соединения и вдумчиво собрать заново, после каждой коммутации тестируя сеть.
Рустам Ногаев: на клиентской стороне В ЛЮБОМ СЛУЧАЕ потребуется делать дополнительные настройки. Вы пытаетесь каждую рабочую станцию в каждом филиале зацепить по отдельному VPN-соединению в единую сеть? Так не делается. Вам нужно объединять СЕТИ. Центрального офиса, и сети филиалов. А для этого на каждой стороне должен стоять предмет, который будет выполнять функции построения туннеля между сетями. И этот предмет нужно будет настраивать С ОБОИХ сторон.
Максим: Да, ограничение на 2 физических процессора убрали сейчас.
Мы работаем и с VMware и с Hyper-V одинаково. Что касается бесплатных версий, то таки Hyper-V предпочтительнее, на мой взгляд. Пусть VMware в конкуретной гонке с Micrisoft и убрала лимиты у ESXi, но кластер на бесплатных ESXi всё равно не построить, тогда как на Hyper-V можно :-) А в остальном, в принципе, особой разницы нет, получается.
Максим: > вы умело опустили мои замечания по поводу ограничений на ресурсы
Маркетологом у VMware трудитесь? :-) Вот цитатка: "Free ESXi 6.0 Limitations
No support
Free ESXi cannot be added to a vCenter Server
2 physical CPUs
Unlimited cores per CPU
Unlimited physical Memory
max. 8 vCPU per VM"
Иными словами, ограничения стали побольше, но это не значит, что их не стало вовсе. 2 физических процессора и невозможность создать виртуалки с более чем 8 процессорами, а также невозможно добавить бесплатный ESX в vCenter. Ну и как следствие -- невозможность кластеризации.
У Hyper-V этих ограничений нет. От слова "вообще". В том числе и кластер из бесплатных Hyper-V можно собрать совершенно свободно.
А насчёт того, что вам ближе esxcli, чем powershell... Ну, это, как говорится, вопрос не технический, а религиозный.
WebDiez: Это вы с чем-то путаете :-) Так не бывает. Пользователь зашёл -- у него запустился сеанс, и он там что-то делает. Увидеть запущенные этим пользователем приложения можно только одним способом -- попав в этот же сеанс. А попасть в этот же сеанс можно тоже только одним способом -- разблокировав комп логином и паролем того пользователя, которым этот сеанс создавался.
АртемЪ: Я согласен. Но защита -- это "комплекс мер", как учит нас методичка. И в этом комплексе, если делать всё по уму, мелочей нет. Поэтому забивать даже на такую слабенькую хрень, как контроль MAC-адресов, не стоит.
Кирилл: Это тока те, кто его готовить не умеет. Hyper-V ни в чём ESX не уступает на текущий момент. Разве что в каких-то специфичных вещах, которые на каждом шагу не встречаются. По крайней мере я, имея опыт работы и с тем, и с другим, с ходу принципиальных отличий не назову. Разве что SC VMM для Hyper-V подглюкивает чаще, чем vCenter, ну и концепция управления сетями сложнее.
Но поскольку вы спрашиваете про собственно гипервизор и его бесплатность -- то Hyper-V Server от ESX отличается в основном тем, что ограничений на ресурсы у него нет. Т.е. ESX в бесплатной версии, например, не даст вам использовать больше 32 Гб на хосте. У Hyper-V такого ограничения нет. Также ESX ограничивает число используемых ядер (до 4-х, вроде бы), а Hyper-V -- нет.
