Если бы SPICE был идеален, то его разработчик (RedHat) не объявил бы о прекращении работ над его развитием и не рекомендовал бы переходить на другие протоколы. https://access.redhat.com/solutions/5414901 Про безопасный доступ, ну очень дискуссионная тема. Предлагаю не погружаться в неё :). Обычно решается установкой специализированного шлюза удалённого доступа.
Для подключения, может быть использован браузер, так же как и в зарубежных решениях, когда в HTML5 (как в транспорт) "заворачивается" оригинальный протокол. У нас в HTML5 можно обернуть протокол TERA.
Если используется нативный (то есть разработанный для конкретной ОС) клиент, то он как раз может и прокидывает устройства в ВМ или в физическую машину (для сценария, где нужен доступ к аппаратному ПК/блейду).
Верно. Если для подключения не используется протокол SPICE (а его тоже можно использовать на поддерживаемых гипервизорах), то взаимодействие идёт Клиентское Рабочее место <--> ВМ, минуя гипервизор. Это кстати позволяет организовать взаимодействие Клиентское Рабочее место <--> Физический ПК в офисе компании.
Разные задачи - разные протоколы. SPICE далеко не идеальный протокол.
Изначально (несколько лет назад) продукт базировался на нескольких Open Source решениях. Сейчас, многие вещи переработаны и код является собственностью "УВЕОН". Например, за основу был взят протокол SPICE, но сейчас есть собственный протокол TERA, на основе SPICE, где избавились от жёсткой привязки к гипервизору и дали возможность работать с физическими ПК.
Коллега, не подскажите, а как "обходится" запрет MS SPLA на предоставление виртуального десктопа с клиентской ОС? Это если про облачную модель говорить.
Алексей, а как-то странно получается — вы пытаетесь смешать 2 варианта — upgrade и установка с нуля. Кто мешал пойти описанным в руководстве путём — обновление в рамках пула одного сервера, а затем второго.
Функционал Live Patching требует платной Enterprise редакции.
Так что я бы определил самой главной ПРОБЛЕМУ 0 — не желание ознакомится с документацией по продукту, а вместо этого принятие решений по изменению конфигурации рабочей среды по принципу "на авось", этакий agile-style — ввяжемся в драку, а там посмотрим, что к чему.
"Я, как владелец фирмы, могу рискнуть и не отдать..." — смелое заявление.
"Продать третьему лицу..." = Закрыть бизнес облачного сервиса
"Стабильность канала связи..." — сертифицированные ЦОДы сервис-провайдеров должны иметь несколько входов от разных провайдеров. Но это же справедливо и для подключения филиалов компании к корпоративному ЦОДу для работы с бизнес-критичными приложениями.
Если обработка данных перенесена в облако, то данные там в облаке и обрабатываются и используются. Просто так, их туда-сюда не гоняют. Шансов на успех будет больше у хакера, атакующего "Рога и Копыта".
В случае использования продукта Citrix NS SD_WAN, для VoIP трафика рекомендуется использовать режим дублирования пакетов по 2-м наиболее подходящим каналам передачи. Подробнее о класификации приложений и способам передачи можно ознакомится в данной статье https://support.citrix.com/article/CTX226263
К сожалению, не знаю к какой области деятельности относится ваша компания. Рассуждения на тему "облака не для России" это часто встречающееся возражение. Но тут проблему перехода к облачным вычислениям надо рассматривать в комплексе — никто не говорит, что все предприятия должны перенести все приложения в облачную среду. И тут, если отказаться от такого рассмотрения обнаружится, что с государством например многие общаются через облачные сервисы, почтовые системы переводят на облачные сервисы, бухгалтерские/финансовые/учётные приложения уже готовы получать как сервис по подписке. Также надо смотреть на размеры компании и сферу её деятельности, и не забывать, что облака бывают разные — публичные, гибридные, частные и коммунальные (community) и сервис который предоставляется из облаков также бывает разный — IaaS, PaaS, SaaS и далее ставим уже тот сервис какой нам нужен — Desktop-as-a-Service, Storage-as-a-Service, Backup-as-a-Service и так далее.
Странный подход. Для того, чтобы один доктор к другому обратился "Коллега!" они не обязаны работать в одной клинике, но вам наверное виднее.
Многие наши заказчики как раз используют виртуализацию для повышения безопасности своих инфраструктур.
Если двигаться дальше, основываясь на вашем подходе, то проблема любой безопасности это человеческий фактор, а не только виртуализации. В любом проекте вопросы безопасности можно решить как техническими, так и организационными (организационно-техническими) методами. Посмотрите в документацию любого вендора по серверной виртуализации и там будет подробно рассказано как осуществить разделение ролей и настроить аудит, чтобы администратор имел минимально необходимые полномочия и его действия в системе регистрировались. Например для Citrix XenSever можно посмотреть Руководство Администратора и Рекомендации по защите это если вас беспокоит возможность получения доступа к виртуальной машине. В статье же рассматривалась в первую очередь виртуализация десктопов и приложений (VDI и терминальный доступ). А учитывая то, что чаще всего данные пользователей отделены от виртуальной машины, которая загружается с "золотого" образа, то смысла в "похищении" образа или снепшота очень мало. Тут скорее придётся заботиться о том, что "злобный" администратор СХД или резервного копирования может похитить пользовательские данные :).
Ну а тараканы похоже у всех разные.
Коллега — странное у вас понятие о безопасности :). Приходи кто хочет и уноси что хочет? А разделение ролей, а шифрование, а контроль физического доступа? К тому же, в статье, речь идёт в первую очередь о безопасности рабочих мест. И если проводить такие же параллели, то там нет никакой безопасности — приходи кто хочет, вставляй флешки, 4G модемы и сливай что хочешь. В рамках виртуальных десктопов это гораздо проще контролируется, и также закрываются вопросы с несвоевременным обновлением клиентской ОС, приложений, быстром устранении выявленных уязвимостей на большом количестве компьютеров.
Версия ESXi? Проверяем поддерживаемые версии для редакции SE — здесь.
Установка выполнялась в соответствии с мануалом?
Проверил в TechSupport — известных проблем с установкой VPX на гипервизор от VMware — нет.
Павел, спасибо за интерес.
Про официальный сайт не соглашусь, так как есть как минимум 2 раздела, где подробно рассматриваются технические аспекты и документация:
Документация где среди прочих есть большое количество документов по настройке решения.
VRF — это один из ключевых механизмов решения.
Я с вами соглашусь, что в статье мало технических подробностей, отчасти это связано с тем, что компанию Citrix по-прежнему воспринимают только как разработчика решений по терминальному доступу, хотя портфель решений компании гораздо больше.
В марте месяце мой коллега проводил вебинар на тему NetScaler SD-WAN с описанием возможностей и особенностей реализации. Если интересно, то материалы (запись и презентацию) можно скачать отсюда
Ну вы же сами на своё замечание ответили. NetScaler SD-WAN коробочный продукт, с большим количеством шаблонов и возможностей определения типов приложений. + определение и переключение осуществляется на основе пакета, что позволяет осуществить такое переключение очень быстро — практически незаметно для пользователя.
А так — вы абсолютно правы, многие вещи можно сделать самому на базе различных продуктов. Тут вопрос будет больше про потраченное время и усилия, в том числе и на сопровождение комплекса в целом.
Статья на которую вы ссылаетесь — описание подходов, применяемых различными вендорами-поставщиками решений SD-WAN. Естественно никто не претендует на то, что в нашем решении «открыта Америка», компания Citrix Systems своей статьёй говорит о том, что если у вас есть многофилиальная сеть, если вы ещё не построили свою инфраструктуру на решениях других вендоров, а также если вы уже применяете наши продукты для удалённого доступа (XenApp, XenDesktop), то… рекомендуем посмотреть на наше решение — NetScaler SD-WAN, который по-мимо WAN-виртуализации и WAN-оптимизации ещё и понимает подканалы нашего протокола ICA (он же HDX), и позволяет например обеспечивать качественную работу с виртуальным Skype for Business — https://youtu.be/Ts4b3JJACKI
А так кончено есть отличия в реализации, но тут очень часто вопрос предпочтений того или иного вендора, особенно если уже что-то развёрнуто или находится в процессе развёртывания.
Речь идёт о решении NetScaler SD-WAN.
В зависимости от редакции это будет или решение по WAN оптимизации или по WAN виртуализации или (для топовой редакции) и то и другое вместе. В состав решения входит также модуль управления. Поставляется решение или как аппаратное решение или как виртуальная машина под одну из 2-х (для WAN-виртуализации) или 3-х (для WAN оптимизации) платформ виртуализации (XenServer, ESXi и Hyper-V)
Если бы SPICE был идеален, то его разработчик (RedHat) не объявил бы о прекращении работ над его развитием и не рекомендовал бы переходить на другие протоколы.
https://access.redhat.com/solutions/5414901
Про безопасный доступ, ну очень дискуссионная тема. Предлагаю не погружаться в неё :).
Обычно решается установкой специализированного шлюза удалённого доступа.
Для подключения, может быть использован браузер, так же как и в зарубежных решениях, когда в HTML5 (как в транспорт) "заворачивается" оригинальный протокол. У нас в HTML5 можно обернуть протокол TERA.
Если используется нативный (то есть разработанный для конкретной ОС) клиент, то он как раз может и прокидывает устройства в ВМ или в физическую машину (для сценария, где нужен доступ к аппаратному ПК/блейду).
И конечно в ВМ ставится агент, к которому происходит подключение.
В целом это, и многое другое, описано в документации - https://wiki.astralinux.ru/termidesk-help/latest
Верно.
Если для подключения не используется протокол SPICE (а его тоже можно использовать на поддерживаемых гипервизорах), то взаимодействие идёт Клиентское Рабочее место <--> ВМ, минуя гипервизор. Это кстати позволяет организовать взаимодействие Клиентское Рабочее место <--> Физический ПК в офисе компании.
Разные задачи - разные протоколы. SPICE далеко не идеальный протокол.
https://wiki.astralinux.ru/termidesk-help/latest/arhitektura#id-.Архитектураv6.0-Схемавзаимодействиякомпонентовипроцессов
RabbitMQ, является брокером сообщений.
Изначально (несколько лет назад) продукт базировался на нескольких Open Source решениях. Сейчас, многие вещи переработаны и код является собственностью "УВЕОН".
Например, за основу был взят протокол SPICE, но сейчас есть собственный протокол TERA, на основе SPICE, где избавились от жёсткой привязки к гипервизору и дали возможность работать с физическими ПК.
Попробуйте приобрести NetScaler и получить по нему техническую поддержку вендора для организации в России.
По идеологии ближе F5 Big-IP и Citrix NetScaler
Валентин, спасибо за гайд, только это нельзя называть VDI. Совсем. Никак.
Коллега, не подскажите, а как "обходится" запрет MS SPLA на предоставление виртуального десктопа с клиентской ОС? Это если про облачную модель говорить.
Алексей, а как-то странно получается — вы пытаетесь смешать 2 варианта — upgrade и установка с нуля. Кто мешал пойти описанным в руководстве путём — обновление в рамках пула одного сервера, а затем второго.
Функционал Live Patching требует платной Enterprise редакции.
Так что я бы определил самой главной ПРОБЛЕМУ 0 — не желание ознакомится с документацией по продукту, а вместо этого принятие решений по изменению конфигурации рабочей среды по принципу "на авось", этакий agile-style — ввяжемся в драку, а там посмотрим, что к чему.
"Я, как владелец фирмы, могу рискнуть и не отдать..." — смелое заявление.
"Продать третьему лицу..." = Закрыть бизнес облачного сервиса
"Стабильность канала связи..." — сертифицированные ЦОДы сервис-провайдеров должны иметь несколько входов от разных провайдеров. Но это же справедливо и для подключения филиалов компании к корпоративному ЦОДу для работы с бизнес-критичными приложениями.
Если обработка данных перенесена в облако, то данные там в облаке и обрабатываются и используются. Просто так, их туда-сюда не гоняют. Шансов на успех будет больше у хакера, атакующего "Рога и Копыта".
В случае использования продукта Citrix NS SD_WAN, для VoIP трафика рекомендуется использовать режим дублирования пакетов по 2-м наиболее подходящим каналам передачи. Подробнее о класификации приложений и способам передачи можно ознакомится в данной статье
https://support.citrix.com/article/CTX226263
К сожалению, не знаю к какой области деятельности относится ваша компания. Рассуждения на тему "облака не для России" это часто встречающееся возражение. Но тут проблему перехода к облачным вычислениям надо рассматривать в комплексе — никто не говорит, что все предприятия должны перенести все приложения в облачную среду. И тут, если отказаться от такого рассмотрения обнаружится, что с государством например многие общаются через облачные сервисы, почтовые системы переводят на облачные сервисы, бухгалтерские/финансовые/учётные приложения уже готовы получать как сервис по подписке. Также надо смотреть на размеры компании и сферу её деятельности, и не забывать, что облака бывают разные — публичные, гибридные, частные и коммунальные (community) и сервис который предоставляется из облаков также бывает разный — IaaS, PaaS, SaaS и далее ставим уже тот сервис какой нам нужен — Desktop-as-a-Service, Storage-as-a-Service, Backup-as-a-Service и так далее.
Странный подход. Для того, чтобы один доктор к другому обратился "Коллега!" они не обязаны работать в одной клинике, но вам наверное виднее.
Многие наши заказчики как раз используют виртуализацию для повышения безопасности своих инфраструктур.
Если двигаться дальше, основываясь на вашем подходе, то проблема любой безопасности это человеческий фактор, а не только виртуализации. В любом проекте вопросы безопасности можно решить как техническими, так и организационными (организационно-техническими) методами. Посмотрите в документацию любого вендора по серверной виртуализации и там будет подробно рассказано как осуществить разделение ролей и настроить аудит, чтобы администратор имел минимально необходимые полномочия и его действия в системе регистрировались. Например для Citrix XenSever можно посмотреть Руководство Администратора и Рекомендации по защите это если вас беспокоит возможность получения доступа к виртуальной машине. В статье же рассматривалась в первую очередь виртуализация десктопов и приложений (VDI и терминальный доступ). А учитывая то, что чаще всего данные пользователей отделены от виртуальной машины, которая загружается с "золотого" образа, то смысла в "похищении" образа или снепшота очень мало. Тут скорее придётся заботиться о том, что "злобный" администратор СХД или резервного копирования может похитить пользовательские данные :).
Ну а тараканы похоже у всех разные.
Коллега — странное у вас понятие о безопасности :). Приходи кто хочет и уноси что хочет? А разделение ролей, а шифрование, а контроль физического доступа? К тому же, в статье, речь идёт в первую очередь о безопасности рабочих мест. И если проводить такие же параллели, то там нет никакой безопасности — приходи кто хочет, вставляй флешки, 4G модемы и сливай что хочешь. В рамках виртуальных десктопов это гораздо проще контролируется, и также закрываются вопросы с несвоевременным обновлением клиентской ОС, приложений, быстром устранении выявленных уязвимостей на большом количестве компьютеров.
Версия ESXi? Проверяем поддерживаемые версии для редакции SE — здесь.
Установка выполнялась в соответствии с мануалом?
Проверил в TechSupport — известных проблем с установкой VPX на гипервизор от VMware — нет.
Павел, спасибо за интерес.
Про официальный сайт не соглашусь, так как есть как минимум 2 раздела, где подробно рассматриваются технические аспекты и документация:
VRF — это один из ключевых механизмов решения.
Я с вами соглашусь, что в статье мало технических подробностей, отчасти это связано с тем, что компанию Citrix по-прежнему воспринимают только как разработчика решений по терминальному доступу, хотя портфель решений компании гораздо больше.
В марте месяце мой коллега проводил вебинар на тему NetScaler SD-WAN с описанием возможностей и особенностей реализации. Если интересно, то материалы (запись и презентацию) можно скачать отсюда
А так — вы абсолютно правы, многие вещи можно сделать самому на базе различных продуктов. Тут вопрос будет больше про потраченное время и усилия, в том числе и на сопровождение комплекса в целом.
Вся документация также в открытом доступе — http://docs.citrix.com/en-us/netscaler-sd-wan.html и https://www.citrix.com/products/netscaler-sd-wan/resources/
А так кончено есть отличия в реализации, но тут очень часто вопрос предпочтений того или иного вендора, особенно если уже что-то развёрнуто или находится в процессе развёртывания.
В зависимости от редакции это будет или решение по WAN оптимизации или по WAN виртуализации или (для топовой редакции) и то и другое вместе. В состав решения входит также модуль управления. Поставляется решение или как аппаратное решение или как виртуальная машина под одну из 2-х (для WAN-виртуализации) или 3-х (для WAN оптимизации) платформ виртуализации (XenServer, ESXi и Hyper-V)