Здравствуйте, BrainSlug, Вы писали:
BS>ну так это клиент. сервер где?
Сервер может быть какой угодно, хоть нейтивный, хоть управляемый.
Я немного не понял вопроса, в чем загвоздка с сервером? Задача терминального сервера ssh — это принимать входные подключения и запускать на каждое соединение какую-нить консольную прогу, перенаправляя на неё stdin/stdout/stderr, аналогично telnet. Настрой так, чтобы на сервере запускался cmd.exe или power shell.
Или ты хотел такую библиотеку на дотнете, чтобы самому построить произвольный SSH-сервер (не обязательно терминальный) как из кубиков?
Типа такого: http://www.nsoftware.com/ipworks/ssh/ ?
S>Не могу себе представить, что бы человек из мира Микрософт, зайдя в мир Джава, сказал что он в восторге. Это не возможно в принципе. Так же, как невозможна объективная дискуссия о том, что лучше.
Возможна. Но только если мы будем сравнивать $$$$$, влитые в проект и время, потраченное на его выпуск на рынок (или представление клиенту-заказчику).
НС>Ага, а WebForms и Wicket остались в начале 2000-х со своей убогой концепцией компонентов, притараненной из гуев.
Ну, контролов для ASPNET Webforms насоздавали больше, чем для MVC. Поэтому если нет желания заниматься с рукоблудием, прикручивая к гриду пейджинг, например, то я, по правде говоря, альтернативу webforms библиотекам контролов плохо представляю. Скриптовые Фреймворки не в счет — там все равно руками ковыряться надо. MVC контролы от тех же производителей, что и для webforms лет 5 назад были сыроваты.
Компания Microsoft встроила в редактор кода Visual Studio инструменты Xamarin, позволяющие вести разработку кросс-платформенных приложений. По словам руководителя "облачного" бизнеса Microsoft Скотта Гатри, инструменты доступны во всех редакциях Visual Studio, включая абсолютно бесплатную Community.
Теперь разработчики, работая из-под Windows, смогут создавать программы для разных операционных систем, будь то iOS, Android или OS X. Кроме того, на конференции BUILD 2016 в Сан-Франциско компания сообщила о намерении выложить в публичный доступ исходный код Xamarin, чтобы любой разработчик смог заглянуть под его "капот" и настроить для собственных нужд.
Подборка: главные приложения марта
В последнее время Microsoft прикладывает большие усилия к тому, чтобы привлечь к Windows как можно больше разработчиков. Ранее на BUILD 2016 компания анонсировала следующее крупное обновление Windows 10 — Anniversary Update. Апдейт впервые привнесет в "операционку" Microsoft командную оболочку bash, которую ранее можно было найти преимущественно в UNIX-подобных системах (Linux, OS X, Solaris, FreeBSD и др.).
Компания Xamarin была основана в 2011 году. Оформив платную подписку, разработчики могли получить доступ к инструментам для написания и отладки программы на языке C# для самых разных платформ. В феврале этого года стартап был куплен Microsoft. Сумма сделки не разглашалась. По данным The Wall Street Journal, Xamarin обошелся ей в $400–500 миллионов.
Microsoft открыла бесплатный доступ к инструментам для создания кроссплатформенных приложений Xamarin для разработчиков, которые используют Visual Studio.
Xamarin доступен не только владельцам платных редакций Visual Studio (Professional или Enterprise), но и тем, кто использует бесплатную версию — Community.
С помощью Xamarin разработчики смогут создавать приложения для различных платформ (iOS, Android, Windows и Mac) на языке C# с использованием .NET, а инструмент Xamarin.Forms позволит написать единый пользовательский интерфейс для всех платформ.
Также Microsoft планирует в течение нескольких месяцев открыть исходный код Xamarin.
Раньше Xamarin продавала свои инструменты по подписке, стоимость которой варьировалась от $299 в год для независимых разработчиков до $999 для бизнеса.
В феврале 2016 года Microsoft объявила о покупке Xamarin. Сделка была закрыта 18 марта, её детали не раскрываются. По данным The Wall Street Journal, Microsoft заплатила за Xamarin от $400 млн до $500 млн.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Cyberax, Вы писали:
C>>>Ну а Hyper-V тормозит как олигофрен на математической олимпиаде. _AB>>По отзывам сисадминов давно уже не тормозит. Тормозила первая версия. C>Он всё ещё тормозит.
В каком из трех режимов виртуализации? Ты о чем сейчас? Ты так и не разобрался, что ле, как хостить виртуалки в Hyper-V в режиме аппаратной паравиртуализации? ))
Начиная с Висты идут встроенные дрова, а на MS-дрова для Линухов я ссылку давал. Попробуй с этими дровами и удивись. В отличие от Hyper-V, KVM на сегодня поддерживает аппаратную паравиртуализацию только на сетевом IO.
C>Но в последних версиях сильно подтянули IO, так что от него рыдать не так сильно хочется.
Да, собсно, все последние годы вокруг только лишь IO хлопоты и происходят, бо пока никакого IO нет, то все виртуалки давно работают одинаково — со скоростью "родного" исполнения. Просто MS раньше других разобралась, как сделать нормальное IO без патча операционки — достаточно подменить дрова на виртуалках, чтобы не возиться с довольно-таки прямолинейной и глупой технологией аппаратной виртуализации. Специальные дрова, в отличие от, вызывают сервисы гипервизора и практически не вносят никакого оверхеда. Уж в сравнении с пропатченным ядром как минимум.
C>Следующий затык у Hyper-V в планировщике. Прерывания в Hyper-V виртуализуются, если процессор не используется эксклюзивно гостевой системой.
И? Продолжай! Для какого режима гипервизора это имеет значение? Откуда прерывания вообще поступают, коллега? ))
Это если драйвер гостевой операционки работает поверх эмулированного оборудования, то происходит упомянутое тобой. А если драйвер напрямую с оборудованием не работает, а вместо этого вызывает сервисы гипервизора, то такой ситуации не происходит от слова вообще.
Я же дал уже достаточно инфы по описанному, чтобы ты смог разобраться самостоятельно (при желании разбираться, ес-но).
C>Ну а виртуализованное прерывание — это в Винде очень тяжеловесная вещь. Потому как только плотность гостей превышает количество CPU, то производительность падает камнем вниз.
Поэтому-то режим аппаратной виртуализации уже много лет как непопулярен для более-менее серьезного хостинга. И не только в Hyper-V.
C>Xen и KVM ведут себя намного лучше за счёт более эффективного планирования в Линуксе.
Планирование в Линуксе доступно для изучения всем желающим. Оно у них тривиальное — на выбор из 3-х алгоритмов, где по умолчанию round robin с приоритетами. Как можно было это назвать "более эффективным" — я ХЗ. ))
В виндах планировщик дополнительно смотрит на очереди потоков к ожидающим примитивам синхронизации и будит именно те потоки, которые зависели от сигнального состояния такого примитива синхронизации. В итоге, на той же технике скорость пробуждения потока на семафоре на виндах составляет сотни наносекунд, а в линухах — от 2-х микросекунд и более.
Здравствуйте, vdimas, Вы писали:
V>В каком из трех режимов виртуализации? Ты о чем сейчас? Ты так и не разобрался, что ле, как хостить виртуалки в Hyper-V в режиме аппаратной паравиртуализации? ))
У меня вот прямо сейчас флот из пары тысяч машин работает. Под Hyper-V. Объяснять он мне ещё будет про то, что Винда умеет крутую виртуализацию.
V>Начиная с Висты идут встроенные дрова, а на MS-дрова для Линухов я ссылку давал. Попробуй с этими дровами и удивись. В отличие от Hyper-V, KVM на сегодня поддерживает аппаратную паравиртуализацию только на сетевом IO.
Я уже привёл ссылку на драйвер из 2003-го года.
C>>Но в последних версиях сильно подтянули IO, так что от него рыдать не так сильно хочется. V>Да, собсно, все последние годы вокруг только лишь IO хлопоты и происходят, бо пока никакого IO нет, то все виртуалки давно работают одинаково — со скоростью "родного" исполнения. Просто MS раньше других разобралась, как сделать нормальное IO без патча операционки — достаточно подменить дрова на виртуалках
Кащенит?
C>>Следующий затык у Hyper-V в планировщике. Прерывания в Hyper-V виртуализуются, если процессор не используется эксклюзивно гостевой системой. V>И? Продолжай! Для какого режима гипервизора это имеет значение? Откуда прерывания вообще поступают, коллега? ))
Для всех.
V>Это если драйвер гостевой операционки работает поверх эмулированного оборудования, то происходит упомянутое тобой.
Прерывания от железных устройств поступают в хост-операционку, которая затем перенаправляет их в нужную виртуалку. И пофиг как именно она их перенаправляет, тормозит сама хост-система.
V>Я же дал уже достаточно инфы по описанному, чтобы ты смог разобраться самостоятельно (при желании разбираться, ес-но).
Вот ещё бы понял о чём речь.
V>В виндах планировщик дополнительно смотрит на очереди потоков к ожидающим примитивам синхронизации и будит именно те потоки, которые зависели от сигнального состояния такого примитива синхронизации.
Ой, блджад. Достижение века! Дайте ему Нобелевскую Премию!
В Линуксе, блждад, планировщик, блждад, гарантирует realtime-ответ с учетом deadline-планирования и наследования приоритетов. Очереди потоков, блджад.
Здравствуйте, Cyberax, Вы писали:
V>>В каком из трех режимов виртуализации? Ты о чем сейчас? Ты так и не разобрался, что ле, как хостить виртуалки в Hyper-V в режиме аппаратной паравиртуализации? )) C>У меня вот прямо сейчас флот из пары тысяч машин работает. Под Hyper-V. Объяснять он мне ещё будет про то, что Винда умеет крутую виртуализацию.
Т.е., так и не разобрался. ЧТД.
Небось, так в режиме аппаратной виртуализации всё у тебя и работает. По-старинке.
Или вы забыли поставить сетевые VMQ-карточки на серваки виртуализации — тоже одна из встречающихся ошибок "фермеров". Или просто забыли включить для них режим VMQ:
Note By default, VMQ is disabled on the Hyper- V virtual switch for virtual machines that are using 1- gigabit network adapters.
В сети полно манулов, как настроить VMQ.
C>Я уже привёл ссылку на драйвер из 2003-го года.
Это не тот год.
код для поддержки работы Linux в роли гостевой системы Hyper-V был открыт компанией Microsoft в 2009 году под лицензией GPLv2 и позднее был включен в состав staging-дерева ядра Linux 2.6.32.
C>>>Но в последних версиях сильно подтянули IO, так что от него рыдать не так сильно хочется. V>>Да, собсно, все последние годы вокруг только лишь IO хлопоты и происходят, бо пока никакого IO нет, то все виртуалки давно работают одинаково — со скоростью "родного" исполнения. Просто MS раньше других разобралась, как сделать нормальное IO без патча операционки — достаточно подменить дрова на виртуалках C>Кащенит?
Ну ты же показал уже парой сообщений выше, что про аппаратную паравиртуализацию в первый раз слышишь.
Лучше бы спрашивал по-существу.
V>>Это если драйвер гостевой операционки работает поверх эмулированного оборудования, то происходит упомянутое тобой. C>Прерывания от железных устройств поступают в хост-операционку, которая затем перенаправляет их в нужную виртуалку. И пофиг как именно она их перенаправляет, тормозит сама хост-система.
Опять и снова ЧТД.
Это происходит именно в режиме аппаратной виртуализации. Более того, чаще всего в этом случае реальное железо подменяется неким эмулятором виртуального (например, абсолютно всегда для сетевого IO, SCSI и IDE-интерфейсов). Именно поэтому нужна трансляция прерываний реального железа на виртуальное. Твои "виртуальные прерывания" — это оно и есть, т.е. это отображения происходящего в реальности на происходящее в эмуляторе железа.
Так вот. Паравиртуальный режим НЕ ТРЕБУЕТ эмуляции оборудования от слова вообще. А в режиме VMQ для обслуживания трафика сетевых карточек вообще может быть использовано любое ядро проца, т.е. не обязательно то, на котором сейчас выполняется целевая гостевая ОС (или пусть она спит), в буфера которой пришли данные по сетке.
Именно так решается проблема "бутылочного горлышка" IO, когда для перекачки данных для гостевой ОС необходимо было устанавливать её контекст в проце. Сейчас этого НЕ требуется. В режиме аппаратной паравиртуализации можно будить гостевую ОС уже по окончании процесса перекачки данных, т.е. сугубо по готовности прикладных сигналов, типа готовности epoll на линухе или completion ports на винде.
Т.е., в режиме аппаратной паравиртуализации ядро хостовой операционки работает в режиме относительно простого гипервизора. Для максимальной отдачи от такого режима гостевая операционка не должна требовать эмулятора железа, а должна обращаться напрямую к высокоуровневым сервисам гипервизора.
Собсно, даже такая фича, как Cluster Shared Volumes без паравиртуализации недостижима, потому что через эмулирование низкоуровневого аппаратного жесткого диска с его секторами и дорожками такой режим шаринга невозможен.
V>>В виндах планировщик дополнительно смотрит на очереди потоков к ожидающим примитивам синхронизации и будит именно те потоки, которые зависели от сигнального состояния такого примитива синхронизации. C>Ой, блджад. Достижение века! Дайте ему Нобелевскую Премию!
C>В Линуксе, блждад, планировщик, блждад, гарантирует realtime-ответ с учетом deadline-планирования и наследования приоритетов. Очереди потоков, блджад.
Что есть "гарантирует realtime-ответ"? Ты имеешь ввиду реалтаймовые расширения ядра или что-то еще? Ты хорошо понимаешь, в чем состоят эти расширения? Готов обсудить (а будет много нареканий с моей стороны, потому что одно время смотрел оч тщательно и оно мне не подошло, ес-но). Или вот только пузыри по верхам будем пускать, шарахаясь от подробностей реально-происходящего? ))
Потому что ты сыпешь терминами, не понимая разницы внутреннего устройства планировщиков, вестимо. Иначе бы не заменял эмоциями отсутсвие представлений о происходящем в реальности. Очередь потоков к примитиву синхронизации — это не есть простая очередь потоков. MSDN довольно подробно объясняет работу шедуллера при ожидании на примитивах синхронизации (семафорах, евентах или блокирующих вызовах АПИ, которые используют эти же примитивы неявно- например, цикл выборки оконных сообщений). Было бы желание узнать. Там твой Linux и рядом не валялся с его примитивным шедуллингом — инфа ведь тоже открыта и по Linux. Именно особенность виндов определять наилучший поток для пробуждения исходя из его времени ожидания на блокирующем примитиве позволила сделать вменяемый GUI даже еще на старинной Win95, т.е. на той технике, где GUI Linux/Unix работал в прямом смысле пошагово. ))
============
Для неверующих простой сценарий: один поток переводит семафор в сигнальное состояние, а другой поток, находящийся в блокирующем ожидании, на этом семафоре просыпается. Необходимо измерить среднее время м/у подачей сигнала в одном потоке и пробуждением во втором. Сделай этот простой тест на виндах и линухах и удивись. Сделай этот тест с ожиданием хотя бы в 10 ms м/у циклами пробуждения/ожидания (это важно!). Там разница до 4-5-ти раз не в пользу Linux.
Собсно, вот у нас по работе идёт выжимка максимума из пропускной способности совершенно диких сетевых карточек. Так вот, чтобы в Linux получить с этих карточек отдачу, мало того, что для этих карточек идут собственные дрова с собственным стеком IP, так еще необходимо вертеться в spin-lock ожидании данных, потому что стоит на линухах уйти в спячку — как получи сразу плюс 3-4 микросекунды задержки на каждый входной пакет. В Windows такая прибавка на той же технике составляет до 1 микросекунды (обычно ~0.5-0.7).
Кароч, разница катастрофична и никакими баззвордами ты её не замылишь, потому что realtime-гарантии — это слишком расплывчато, это просто некие гарантии на некое время. А каков ПОРЯДОК этого времени? Например, гарантия в 15.625 ms (64 тика в секунду)? А что? Раз есть "гарантия", то назовём это "realtime"! А по факту именно с малыми задержками в линухах всё очень и очень плохо, даже в случае реалтаймового расширения ядра. Потому что философия изначально пакетная, какими бы ты deadline-планированиями это не обкладывал — там порядок точности не тот.
Даже взять звуковой ASIO для профессиональных внешних звуковух — под виндами размер буферов 2-3ms является нормой, в то время как для линухов на той же технике требуется буфер порядка 10ms. От така херня, малята.
Здравствуйте, Cyberax, Вы писали:
V>>В каком из трех режимов виртуализации? Ты о чем сейчас? Ты так и не разобрался, что ле, как хостить виртуалки в Hyper-V в режиме аппаратной паравиртуализации? )) C>У меня вот прямо сейчас флот из пары тысяч машин работает. Под Hyper-V. Объяснять он мне ещё будет про то, что Винда умеет крутую виртуализацию.
I ran a suite of 26 tests in Phoronix. From the looks of the tests, the majority were CPU intensive. Some were a mixture (7-zip or BZIP compression and PostgreSQL transactions per second), and some were I/O intensive.
The I/O intensive tasks had the greatest variation.
For example, here are some results from a "Threaded I/O Write" test. Numbers are MB/sec, so higher is better :
HyperV-OneVM 306
HyperV-TwoVM-Dev 228
HyperV-TwoVM-Stage 215
ESXi-OneVM 11
ESXi-TwoVM-Dev 56
ESXi-TwoVM-Stage 41
KVM-OneVM-Dev 9
KVM-TwoVM-Dev 13
KVM-TwoVM-Stage 9
VirtualBox-OneVM-Dev 73
И коммент к нему:
What sort of guest OS were you testing with? Were you using the accelerated virtual disk and network adapters that Hyper-V, KVM, and VMware provide?
I ask primarily because the Hyper-V disk performance is so much higher than the others that I'm led to believe it's "cheating" and using a caching layer of some sort.
If Hyper-V isn't actually flushing changes to disk before letting the guest happily continue to make filesystem changes then this could account for both the I/O and other benchmarks being higher than the competitors.
Да, "читерство" и есть, а происходящее описано верно. В то время как KVM до сих пор не поддерживает аппаратную паравиртуализацию дискового IO, Hyper-V поддерживает её изкаробки.
This is a summary of the findings using the HEPSpec 06 benchmark on KVM and a comparison with Hyper-V for the same workload.
For KVM on this workload, we saw a degradation in performance on large VMs.
...
One of the tests when we saw a significant overhead on the default KVM configuration was to compare the performance overheads for a Linux configuration on Hyper-V. Interestingly, Hyper-V achieved better performance without tuning compared to the configurations with KVM. Equivalent tests on Hyper-V showed
4 VMs 8 cores: 0.8% overhead compared to bare metal
1 VM 32 cores: 3.3% overhead compared to bare metal
Итого, взять исходную систему с 32-мя ядрами, запустить на ней Hiper-V, в нём 4 виртуалки по 8 ядер, получим всего 0.8% оверхеда в сравнении с не-эмулируемым исполнением.
В ближайшие годы KVM такое не покажет. На сегодня соответствующий оверхед KVM 2.5% (vs 0.8%) и 13% (vs 3.3%).
Здравствуйте, vdimas, Вы писали:
V>Да, "читерство" и есть, а происходящее описано верно. В то время как KVM до сих пор не поддерживает аппаратную паравиртуализацию дискового IO, Hyper-V поддерживает её изкаробки.
Чувак сравнил производительность эмулируемой карты с драйвером, использующим гипервызовы.
Стандартный virtio-драйвер использует прямое отображение без всякой эмуляции. Не достаточно? Можно отобразить напрямую железку через PCI passthrough: http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM — она будет работать со скоростью железки.
V>One of the tests when we saw a significant overhead on the default KVM configuration was to compare the performance overheads for a Linux configuration on Hyper-V. Interestingly, Hyper-V achieved better performance without tuning compared to the configurations with KVM. Equivalent tests on Hyper-V showed
Ещё больший бред или безграмотность. Они не могли включить passthrough?
V>В ближайшие годы KVM такое не покажет. На сегодня соответствующий оверхед KVM 2.5% (vs 0.8%) и 13% (vs 3.3%).
Бред. KVM местами работает быстрее родного железа из-за побочных эффектов.
Здравствуйте, Cyberax, Вы писали:
V>>Да, "читерство" и есть, а происходящее описано верно. В то время как KVM до сих пор не поддерживает аппаратную паравиртуализацию дискового IO, Hyper-V поддерживает её изкаробки. C>Чувак сравнил производительность эмулируемой карты с драйвером, использующим гипервызовы.
Да. Потому что KVM до сих пор умеет вызовы гипервизора только для сетки. В случае же дискового IO — увы, увы. И не того чувака и не MS это вина, а вина тех, кто не в состоянии для KVM написать паравиртуальные дрова. В отличие от, MS давно для линухохв написала паравиртуальные дрова HD для Hyper-V.
Не будет, в случае возникновения бутылочного горлышка в IO.
V>>One of the tests when we saw a significant overhead on the default KVM configuration was to compare the performance overheads for a Linux configuration on Hyper-V. Interestingly, Hyper-V achieved better performance without tuning compared to the configurations with KVM. Equivalent tests on Hyper-V showed C>Ещё больший бред или безграмотность. Они не могли включить passthrough?
А ты по ссылке не ходил? Там куча тюнинга была. В одном месте пол-процента подтянули, в другом четверть. А у тебя опять "бред и безграмотность", хотя ты ты даже не соизволил стать в курсе, о чем там речь, но уже бежишь возражать. Похвально, чо )) Ты с чем споришь-то?
V>>В ближайшие годы KVM такое не покажет. На сегодня соответствующий оверхед KVM 2.5% (vs 0.8%) и 13% (vs 3.3%). C>Бред. KVM местами работает быстрее родного железа из-за побочных эффектов.
Без IO они все работают с родной скоростью железа, слава богу, хоть KVM хоть кто угодно. Всё различие виртуалок на сегодня — это в кач-ве обслуживания IO. И это кач-во в KVM пока не лучшее на сейчас.
Хотя, сдается мне, если MS достигла 0.8% оверхеда, то это уже "область насыщения". Рано или поздно к этим цифрам подберутся и опенсорные поделия.
Здравствуйте, vdimas, Вы писали:
C>>Чувак сравнил производительность эмулируемой карты с драйвером, использующим гипервызовы. V>Да. Потому что KVM до сих пор умеет вызовы гипервизора только для сетки. В случае же дискового IO — увы, увы.
Хватит бредить.
См.: http://lxr.free-electrons.com/source/drivers/block/virtio_blk.c
Который посылает запросы через: http://lxr.free-electrons.com/source/drivers/virtio/virtio_ring.c#L129
C>>Стандартный virtio-драйвер использует прямое отображение без всякой эмуляции. Не достаточно? V>Ну ты найди идиотов и перед ними свои потоки сознания распускай. А здесь требуется давать свой поинт в понятном виде.
В драйверах IO и сети в KVM не требуется гипервызов для обработки пакетов. От слова "вообще". Хост-система просто асинхронно кладёт их в кольцо, отображаемое на память гостя, а гость их оттуда читает.
Это то, что ты громко назвал "аппаратная паравиртуализация". И то что было в линуксовых драйверах виртуальных устройств аж с 2006-го года.
C>>Можно отобразить напрямую железку через PCI passthrough: http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM — она будет работать со скоростью железки. V>Не будет, в случае возникновения бутылочного горлышка в IO.
Пииииип.
В случае passthrough хост-система ВООБЩЕ не трогает устройство.
C>>Ещё больший бред или безграмотность. Они не могли включить passthrough? V>А ты по ссылке не ходил? Там куча тюнинга была. В одном месте пол-процента подтянули, в другом четверть.
Ходил. Они всё неправильно делают.
C>>Бред. KVM местами работает быстрее родного железа из-за побочных эффектов. V>Без IO они все работают с родной скоростью железа, слава богу, хоть KVM хоть кто угодно. Всё различие виртуалок на сегодня — это в кач-ве обслуживания IO. И это кач-во в KVM пока не лучшее на сейчас.
Вот как раз с IO.
V>Хотя, сдается мне, если MS достигла 0.8% оверхеда, то это уже "область насыщения". Рано или поздно к этим цифрам подберутся и опенсорные поделия.
Вот прямо сейчас кластер на KVM считает терабайты данных быстрее всех в мире.
Здравствуйте, Cyberax, Вы писали:
C>>>Чувак сравнил производительность эмулируемой карты с драйвером, использующим гипервызовы. V>>Да. Потому что KVM до сих пор умеет вызовы гипервизора только для сетки. В случае же дискового IO — увы, увы. C>Хватит бредить.
Да это ты бредишь со своими с 2006-го года.
Всё, с вопросом я разобрался. Ты как всегда, кароч. ))
Это ссылки на дрова IBM из LGuest, который был целиком включен в KVM только в 6-й его версии в 2013-м году. Для примера, сейчас на большинстве серваков в и-нете работают RHEL6-совместимые сборки, в них изкаробки (репозиториев) стоит более старая версия KVM. С полной поддержкой всего, о чем ты говоришь, пошел только RHEL 7.1, он вышел декабре прошлого года (4 месяца назад), и я этот RHEL 7.1 еще не смотрел.
We use the term backporting to describe the action of taking a fix for a security flaw out of the most recent version of an upstream software package and applying that fix to an older version of the package we distribute.
Backporting is common among vendors like Red Hat and is essential to ensuring we can deploy automated updates to customers with minimal risk. Backporting might be a new concept for those more familiar with proprietary software updates.
Твой 6-й KVM еще относительно долго периодически зависал без признаков жизни в различных сценариях, чтобы заслужить быть включенным в репозиторий. Вот откуда растут ноги у разных "реальностей" вокруг KVM.
C>>>Стандартный virtio-драйвер использует прямое отображение без всякой эмуляции. Не достаточно? V>>Ну ты найди идиотов и перед ними свои потоки сознания распускай. А здесь требуется давать свой поинт в понятном виде. C>В драйверах IO и сети в KVM не требуется гипервызов для обработки пакетов. От слова "вообще". Хост-система просто асинхронно кладёт их в кольцо, отображаемое на память гостя, а гость их оттуда читает.
ОК, пару лет назад сделали так же, как в виндах еще со времен Hiver-V на сервере 2008.
Более того, на сегодня для работы в KVM саму виртуалку еще надо правильно настроить, т.к. везде прямо надо прописывать, например /dev/vda0 вместо /dev/hda0, и не только в mount/fstab и сама виртуалка должна содержать желательно ядро от 3-й версии и выше. Кароч, там приседаний дохрена надо совершить над виртуалкой, чтобы заставить вменяемо под KVM работать.
C>Это то, что ты громко назвал "аппаратная паравиртуализация". И то что было в линуксовых драйверах виртуальных устройств аж с 2006-го года.
А вот тут брехня и есть. Курить IBM LGuest. Собсно, именно эту технологию выбрали для KVM, начиная с 6-й версии. Собсно, ты ссылку на исходники IBM и дал. И мои ссылки, данные ранее — они отражают ситуацию на 2013-й год, когда для блочных устройств в KVM еще не было этих дров, т.е. модули айбиэмовского virtio изначально попали в KVM не все и не сразу.
V>>Не будет, в случае возникновения бутылочного горлышка в IO. C>В случае passthrough хост-система ВООБЩЕ не трогает устройство.
А кто трогает? Гостевая? Через свой драйвер? И сама же должна обрабатывать прерывания? А если она вытеснена в этот момент?
Я же тебе давал ключевое для Hyper-V — VMQ, где для общения по сетке не требуется, чтобы работала гостевая ОС — бОльшая часть протоколов из стека Ethernet и IP выполняется на уровне "железных" дров гипервизора. Быстрее на сегодня просто некуда. И на завтра быстрее тоже не будет.
V>>А ты по ссылке не ходил? Там куча тюнинга была. В одном месте пол-процента подтянули, в другом четверть. C>Ходил. Они всё неправильно делают.
Тем не менее, они в итоге добились таких же результатов, какие я вот сижу, читаю на официальном сайте KVM, т.е. порядка 2% оверхеда в среднем (кроме одного специфического теста, где KVM оказался быстрее железа). Причем, на том же официальном сайте пишут, что без тюнинга порой можно получить падение производительности операций IO до 3-х раз (на 10GB картейках, например).
C>>>Бред. KVM местами работает быстрее родного железа из-за побочных эффектов. V>>Без IO они все работают с родной скоростью железа, слава богу, хоть KVM хоть кто угодно. Всё различие виртуалок на сегодня — это в кач-ве обслуживания IO. И это кач-во в KVM пока не лучшее на сейчас. C>Вот как раз с IO.
Угу, видел один из тестов на 1.5% быстрее, чем в железе. Ну чё, лишняя буферизация помогла. А не было такого же теста на этом же железе этого же софта под Hyper-V или даже просто под родными виндами? А то как бы не выяснилось, что под виндами оно изначально быстрее пашет, просто в родных линухах притормаживало. )) Например, в плане сетевого IO так и есть, сетевая подсистема в виндах более шустрая (overlapped IO). В линухах даже АПИ сравнимого нет, по epoll мы получаем лишь сигнал готовности данных и эти данные еще надо прочитать в наш буфер, а в виндах мы получаем сигнал уже когда ядро заполнило данными наши юзверские буфера. Мы при этом сначала запускаем новую overlapped-операцию и одновременно с ней разбираем пришедшую порцию. Сравнить с linux, где выгребание данных проиходит строго поочередно в том же потоке, в котором эти данные ожидаются по epoll.
Например, в линухах нельзя из 10Gb карточки выжать именно 10Gb, там примерно 9.3 выжимают, а в виндах именно что 10. Вполне допускаю, что лишнее буферирование может дать некий прирост. Т.е. поможет распараллелить происходящее, ведь общение по virtio_ring (согласно твоим исходникам) — это точная калька с overlapped IO: подготовили буфера, инициировали операцию и вышли из ф-ии. Жаль, что на сегодня эта техника используется лишь для виртуальных дров, т.е. жаль, что подставляются внутренние буфера ядра, а не юзверские. Например, в overlapped IO мы можем зациклить достаточное кол-во юзверских буферов, т.е. подавать их с неким опережением (инициировать операцию с большим кол-вом буферов, чем надо для одной итерации "ожидание <--> обработка". До тех пор, пока будет хватать юзверских буферов, данные из сетевой картейки будут заливаться непосредственно в юзвеские буфера, исключая промежуточное их копирование, что для 10Gb трафика имеет значение. Аналогично при отправке — можно инициировать ДВЕ overlapped операции, затем, когда придёт сигнал о готовности первой, мы отправим еще данные (в этом время будет обрабатываться вторая операция) и так далее, типа как в 3D используют минимум два буфера рендеринга — пока один отображается, другой готовится. Т.е. в случае отправки данных в виндах тоже получается распараллелить процессы заливки/отправки данных. В АПИ же Linux эти операции выполняются строго поочередно: ожидание готовности устройства для записи (ожидание свободных буферов) и только затем копирование данных в этот буфер через send.
V>>Хотя, сдается мне, если MS достигла 0.8% оверхеда, то это уже "область насыщения". Рано или поздно к этим цифрам подберутся и опенсорные поделия. C>Вот прямо сейчас кластер на KVM считает терабайты данных быстрее всех в мире.
Я не понимаю выражения "считает терабайты данных". Если речь о вычислениях, то быстрее всего считают специально-заточенные на вычисления кластеры на обычной операционке, а не виртуальной.
Здравствуйте, vdimas, Вы писали:
V>>>Да. Потому что KVM до сих пор умеет вызовы гипервизора только для сетки. В случае же дискового IO — увы, увы. C>>Хватит бредить. V>Да это ты бредишь со своими с 2006-го года.
Я привёл ссылку на _исходник_.
C>>См.: http://lxr.free-electrons.com/source/drivers/block/virtio_blk.c C>>Который посылает запросы через: http://lxr.free-electrons.com/source/drivers/virtio/virtio_ring.c#L129 V>Это ссылки на дрова IBM из LGuest, который был целиком включен в KVM только в 6-й его версии в 2013-м году.
Нету их в KVM. Они в ядре. В KVM только механизм virtio.
V>Для примера, сейчас на большинстве серваков в и-нете работают RHEL6-совместимые сборки
Во-первых, не так. Но даже если предположить, что это так, то...
V>в них изкаробки (репозиториев) стоит более старая версия KVM. С полной поддержкой всего, о чем ты говоришь, пошел только RHEL 7.1, он вышел декабре прошлого года (4 месяца назад), и я этот RHEL 7.1 еще не смотрел.
...вот ссылка на virtio в ядре 2.6.32, который в RHEL6: http://lxr.free-electrons.com/source/drivers/virtio/virtio_ring.c?v=2.6.32
V>Твой 6-й KVM еще относительно долго периодически зависал без признаков жизни в различных сценариях, чтобы заслужить быть включенным в репозиторий. Вот откуда растут ноги у разных "реальностей" вокруг KVM.
Бредим.
C>>В драйверах IO и сети в KVM не требуется гипервызов для обработки пакетов. От слова "вообще". Хост-система просто асинхронно кладёт их в кольцо, отображаемое на память гостя, а гость их оттуда читает. V>ОК, пару лет назад сделали так же, как в виндах еще со времен Hiver-V на сервере 2008. Это сделали в 2003-м году в Линуксе. Ещё до Hyper-V и вообще до широкой виртуализации на x86.
V>Более того, на сегодня для работы в KVM саму виртуалку еще надо правильно настроить, т.к. везде прямо надо прописывать, например /dev/vda0 вместо /dev/hda0, и не только в mount/fstab и сама виртуалка должна содержать желательно ядро от 3-й версии и выше. Кароч, там приседаний дохрена надо совершить над виртуалкой, чтобы заставить вменяемо под KVM работать.
О боже мой...
C>>Это то, что ты громко назвал "аппаратная паравиртуализация". И то что было в линуксовых драйверах виртуальных устройств аж с 2006-го года. V>А вот тут брехня и есть. Курить IBM LGuest. Собсно, именно эту технологию выбрали для KVM, начиная с 6-й версии.
Какой 6-й версии, что за бред?
LGuest — это bare-metal гипервизор, аналог Xen. Он является конкурентом KVM, а не "технология для KVM".
C>>В случае passthrough хост-система ВООБЩЕ не трогает устройство. V>А кто трогает? Гостевая? Через свой драйвер?
ДА!
V>И сама же должна обрабатывать прерывания?
Конечно.
V>А если она вытеснена в этот момент?
Вот только тогда оно будет доставлено в хост-систему, которая разбудит гостя.
V>Я же тебе давал ключевое для Hyper-V — VMQ, где для общения по сетке не требуется, чтобы работала гостевая ОС — бОльшая часть протоколов из стека Ethernet и IP выполняется на уровне "железных" дров гипервизора. Быстрее на сегодня просто некуда. И на завтра быстрее тоже не будет.
Headdesk.
Самый быстрый сейчас стек — это userspace-реализация в DPDK. Который, о ужас, поддерживается в KVM: http://dpdk.org/doc/guides/nics/virtio.html . Ну или напрямую через PCI passthrough.
V>Причем, на том же официальном сайте пишут, что без тюнинга порой можно получить падение производительности операций IO до 3-х раз (на 10GB картейках, например).
Для CERN мы делали чисто софтовый маршрутизатор на 30ГБ на машину. Да-да, с виртуализацией.
V>Угу, видел один из тестов на 1.5% быстрее, чем в железе. Ну чё, лишняя буферизация помогла. А не было такого же теста на этом же железе этого же софта под Hyper-V или даже просто под родными виндами? А то как бы не выяснилось, что под виндами оно изначально быстрее пашет, просто в родных линухах притормаживало. ))
Нет.
V>Например, в плане сетевого IO так и есть, сетевая подсистема в виндах более шустрая (overlapped IO). В линухах даже АПИ сравнимого нет, по epoll мы получаем лишь сигнал готовности данных и эти данные еще надо прочитать в наш буфер, а в виндах мы получаем сигнал уже когда ядро заполнило данными наши юзверские буфера. Мы при этом сначала запускаем новую overlapped-операцию и одновременно с ней разбираем пришедшую порцию. Сравнить с linux, где выгребание данных проиходит строго поочередно в том же потоке, в котором эти данные ожидаются по epoll.
V>Например, в линухах нельзя из 10Gb карточки выжать именно 10Gb, там примерно 9.3 выжимают, а в виндах именно что 10. Вполне допускаю, что лишнее буферирование может дать некий прирост.
Если нужна wire speed, то используется сокет типа PF_RING, когда драйвер напрямую доставляет пакеты в userspace-кольцо.
C>>Вот прямо сейчас кластер на KVM считает терабайты данных быстрее всех в мире. V>Я не понимаю выражения "считает терабайты данных". Если речь о вычислениях, то быстрее всего считают специально-заточенные на вычисления кластеры на обычной операционке, а не виртуальной.
Да, специально заточенные кластеры, для научных вычислений (и не только). На вполне себе KVM с особым цинизмом.
KVM — это kernel virtual machine. Поддержка виртуализации и есть в ядре. Например, ядро с поддержкой KVM и ядро с поддержкой Xen — это разные ядра (собранные с разными опциями/зависимостями).
V>>Для примера, сейчас на большинстве серваков в и-нете работают RHEL6-совместимые сборки C>Во-первых, не так.
Во-первых, это так, большинство клиентов сидят на 6.x, даже не смотря на то, что вышел 7.1, т.к. большинство предпочитает начинать с минорной версии 2, не раньше.
V>>в них изкаробки (репозиториев) стоит более старая версия KVM. С полной поддержкой всего, о чем ты говоришь, пошел только RHEL 7.1, он вышел декабре прошлого года (4 месяца назад), и я этот RHEL 7.1 еще не смотрел. C>...вот ссылка на virtio в ядре 2.6.32, который в RHEL6: C>http://lxr.free-electrons.com/source/drivers/virtio/virtio_ring.c?v=2.6.32
Упс, это только модули со стороны ядра. Со стороны гостевой ОС должны быть драйверы, конкретно для блочных устройств это virtio_blk. Не хочешь продолжить свои исследования? ))
V>>Твой 6-й KVM еще относительно долго периодически зависал без признаков жизни в различных сценариях, чтобы заслужить быть включенным в репозиторий. Вот откуда растут ноги у разных "реальностей" вокруг KVM. C>Бредим.
Ну и бредь.
C>>>Это то, что ты громко назвал "аппаратная паравиртуализация". И то что было в линуксовых драйверах виртуальных устройств аж с 2006-го года. V>>А вот тут брехня и есть. Курить IBM LGuest. Собсно, именно эту технологию выбрали для KVM, начиная с 6-й версии. C>Какой 6-й версии, что за бред?
И точно бред:
How to use Virtio
Get kvm version >= 60
C>LGuest — это bare-metal гипервизор, аналог Xen. Он является конкурентом KVM, а не "технология для KVM".
KVM в версии 6 мигрировала на технологию VirtIO из LGuest. Ты даешь исходники именно на код из последнего. Осталось узнать, когда вышла KVM 6.0 и навсегда перестать растопыривать пальцы вейером. Я же тебе сразу сказал — ты как только с Луны. Т.е. этой областью ты занялся относительно недавно.
C>>>В случае passthrough хост-система ВООБЩЕ не трогает устройство. V>>А кто трогает? Гостевая? Через свой драйвер? C>ДА!
Ответ правильный. Поэтому-то бутылочное горлышко.
virtio-blk, минусы:
Ограничения проброса SCSI (passthrough):
нет multipath;
HBA адаптер не может участвовать в миграциях виртуальной машины;
чтобы отправить SCSI команду, виртуальное окружение должно иметь эксклюзивный доступ к диску; две виртуальных машины не могут использовать устройство одновременно.
V>>И сама же должна обрабатывать прерывания? C>Конечно.
19-й век.
V>>А если она вытеснена в этот момент? C>Вот только тогда оно будет доставлено в хост-систему, которая разбудит гостя.
Похоже, ты не понимаешь, как работает DMA, ы-ы-ы. Канал DMA будет занят, пока гость не проснется для обработки прерывания от него по окончании передачи. А гость может не проснуться еще долго (зависит от ситуации в других виртуалках тоже). Кароч, тебя понесло не туда. Ты занялся рекламой вредного режима.
C>Самый быстрый сейчас стек — это userspace-реализация в DPDK.
Маркетинговый булшит. Ничем серьезно от того же Solarflare на OpenOnload ни по каким меркам не отличается.
Да-да, мы в курсе. И всё это сливает VMQ, если карточка не используется виртуалкой эксклюзивно.
V>>Причем, на том же официальном сайте пишут, что без тюнинга порой можно получить падение производительности операций IO до 3-х раз (на 10GB картейках, например). C>Для CERN мы делали чисто софтовый маршрутизатор на 30ГБ на машину. Да-да, с виртуализацией.
Ну вот и спалился. 30Gb на машину не то же самое, что 10Gb на карточку.
V>>Угу, видел один из тестов на 1.5% быстрее, чем в железе. Ну чё, лишняя буферизация помогла. А не было такого же теста на этом же железе этого же софта под Hyper-V или даже просто под родными виндами? А то как бы не выяснилось, что под виндами оно изначально быстрее пашет, просто в родных линухах притормаживало. )) C>Нет.
Кто бы сомневался.
V>>Например, в плане сетевого IO так и есть, сетевая подсистема в виндах более шустрая (overlapped IO). В линухах даже АПИ сравнимого нет, по epoll мы получаем лишь сигнал готовности данных и эти данные еще надо прочитать в наш буфер, а в виндах мы получаем сигнал уже когда ядро заполнило данными наши юзверские буфера. Мы при этом сначала запускаем новую overlapped-операцию и одновременно с ней разбираем пришедшую порцию. Сравнить с linux, где выгребание данных проиходит строго поочередно в том же потоке, в котором эти данные ожидаются по epoll. C>
Согласен. 19-й век. Даже используя OpenOnload. Без прокрутки в спине ожидания Linux работать адекватно отказывается. Стоит уйти в спячку — и всему хана, из-за медленного пробуждения. А спин ожидания — это целое простаивающее ядро. Как ни крути, а г-но на палочке.
V>>Например, в линухах нельзя из 10Gb карточки выжать именно 10Gb, там примерно 9.3 выжимают, а в виндах именно что 10. Вполне допускаю, что лишнее буферирование может дать некий прирост. C>Если нужна wire speed, то используется сокет типа PF_RING, когда драйвер напрямую доставляет пакеты в userspace-кольцо.
Если нужна wire speed, то необходимо и достаточно, чтобы каждый приходящий по сетке пакет было куда складывать и чтобы по готовности устройства к записи было откуда взять данные и записать в него. Так просто, но недоступно на Linux.
Просто ты не понимаешь отличия реактора от проактора, вестимо, раз советуешь какую-то хрень. В Виндах ты можешь спокойно пользоваться обычным IP стеком. А в Линухах ты мне предлагаешь самому разбирать сырые пакеты? Более того, если открыли сокет по PF_RING, то на карточке обычный networking становится недоступным (отпадут другие открытые соединения на этой карточке). И весь этот геммор вместо того, чтобы добавить, наконец, простейшее АПИ для работы в режиме проактора?
C>>>Вот прямо сейчас кластер на KVM считает терабайты данных быстрее всех в мире. V>>Я не понимаю выражения "считает терабайты данных". Если речь о вычислениях, то быстрее всего считают специально-заточенные на вычисления кластеры на обычной операционке, а не виртуальной. C>Да, специально заточенные кластеры, для научных вычислений (и не только). На вполне себе KVM с особым цинизмом.
Зачем KVM? Вы машинное время предоставляете? ))
Да ты точно под веществами, если пытаешься сравнивать это с суперкомпьютерами, которые на сегодня собираются исключительно как банальный кластер, то бишь просто узлы, соединённые быстрыми картейками, типа как у вас. Там разница в производительности в разы выходит, если взять единую задачу, которая потребует ресурсы всего кластера. Потому что ваш кластер под такие вычисления не заточен, он заточен на сдачу в аренду машинного времени на виртуальном оборудовании, в которых кол-во ядер на виртуалку не больше реального на узле.
Кароч, не вводи в заблуждение. У вас банальное "уплотнение", типа как в телефонии, а не "быстрее всех в мире".
Здравствуйте, vdimas, Вы писали:
C>>Я привёл ссылку на _исходник_. V>Это исходники IBM LGuest, которые на тот момент никаким боком к KVM не относились.
Это исходники драйверов для virtio, которые никоим образом к lguest не относятся.
V>KVM — это kernel virtual machine. Поддержка виртуализации и есть в ядре. Например, ядро с поддержкой KVM и ядро с поддержкой Xen — это разные ядра (собранные с разными опциями/зависимостями).
Нет. KVM — это просто ядерный модуль, который позволяет использовать возможности виртуализации CPU. Он не имеет зависимостей сам по себе и может использоваться для запуска совершенно немодифицированных операционок (даже 16-битных).
В пользовательском пространстве KVM'ом обычно управляет qemu, но это не является обязательным.
Xen — это bare-metal гипервизор, который может использовать Linux в качестве гостя (domU) и как хост-систему (dom0). Гость может быть совершенно не модифицированным.
Ну а Virtio — это механизм создания эффективных драйверов для гостевых систем и может использоваться разными гипервизорами. Он существует в немного разных формах с 2003-го года, когда IBM добавила его для OS/390. Для сети и блочных устройств он появился в 2006-м году в Линуксе. Сейчас его поддерживает qemu, Xen и (о ужас!) Hyper-V.
V>http://lxr.free-electrons.com/source/drivers/virtio/?v=2.6.32 V>Упс, это только модули со стороны ядра. Со стороны гостевой ОС должны быть драйверы, конкретно для блочных устройств это virtio_blk. Не хочешь продолжить свои исследования? ))
Это драйверы именно ГОСТЕВОЙ ОС. Со стороны хост-OS ничего не надо, так что Virtio можно использовать даже в режиме полной эмуляции qemu, в том числе для другой архитектуры.
Вот код хост-стороны того же virtio net: https://github.com/qemu/qemu/blob/331ac65963ab74dd84659b748affa0b111486f06/hw/net/virtio-net.c Там же и timestamp времени создания файла — 2007-й год.
V>>>Твой 6-й KVM еще относительно долго периодически зависал без признаков жизни в различных сценариях, чтобы заслужить быть включенным в репозиторий. Вот откуда растут ноги у разных "реальностей" вокруг KVM. C>>Бредим.
"6-й KVM" достоин отдельного лулза.
C>>Какой 6-й версии, что за бред? V>И точно бред: V>
V>How to use Virtio
V> Get kvm version >= 60
Это не версия 6.0, это версия 60. В KVM они увеличивалась каждый tarball-релиз до объединения в официальное ядро и некоторое время после. Сейчас у неё нет своей нумерации версий.
Тот релиз соответствует ядру 2.6.25, которое было 17 апреля 2008-го года.
V>KVM в версии 6 мигрировала на технологию VirtIO из LGuest. Ты даешь исходники именно на код из последнего. Осталось узнать, когда вышла KVM 6.0 и навсегда перестать растопыривать пальцы вейером.
Да я понимаю, ты нахватался слов из wiki-страниц, часто написанных в районе 2010-го года не очень грамотными студентами. Реального опыта у тебя полный ноль.
V>Ограничения проброса SCSI (passthrough): V> нет multipath; V> HBA адаптер не может участвовать в миграциях виртуальной машины; V> чтобы отправить SCSI команду, виртуальное окружение должно иметь эксклюзивный доступ к диску; V> две виртуальных машины не могут использовать устройство одновременно.
Ух ты! Прямой доступ к железу означает прямой доступ к железу!
V>Похоже, ты не понимаешь, как работает DMA, ы-ы-ы. Канал DMA будет занят, пока гость не проснется для обработки прерывания от него по окончании передачи.
Усиленно читаем вики-статьи про IOMMU.
C>>Самый быстрый сейчас стек — это userspace-реализация в DPDK. V>Маркетинговый булшит. Ничем серьезно от того же Solarflare на OpenOnload ни по каким меркам не отличается.
Можно и его. Это тот же DPDK, но только не от Intel.
C>>Для CERN мы делали чисто софтовый маршрутизатор на 30ГБ на машину. Да-да, с виртуализацией. V>Ну вот и спалился. 30Gb на машину не то же самое, что 10Gb на карточку.
Можно и на карту. Зависит от потребностей.
V>Согласен. 19-й век. Даже используя OpenOnload. Без прокрутки в спине ожидания Linux работать адекватно отказывается. Стоит уйти в спячку — и всему хана, из-за медленного пробуждения. А спин ожидания — это целое простаивающее ядро. Как ни крути, а г-но на палочке.
Читаем как работает NAPI.
V>Если нужна wire speed, то необходимо и достаточно, чтобы каждый приходящий по сетке пакет было куда складывать и чтобы по готовности устройства к записи было откуда взять данные и записать в него. Так просто, но недоступно на Linux. http://man7.org/linux/man-pages/man3/aio_read.3.html
C>>Да, специально заточенные кластеры, для научных вычислений (и не только). На вполне себе KVM с особым цинизмом. V>Зачем KVM? Вы машинное время предоставляете? ))
Например, для миграции с плохого железа и для оптимизации сетевой топологии в ходе работы. Миграция особенно важна — кластеры на MPI редко переживают остановку отдельных машин. А если машин несколько тысяч и задача требует пару дней счёта, то такая вероятность начинает быть вполне себе значительной.
Здравствуйте, Cyberax, Вы писали: C>При образ зашивается найстройка PAM, которая использует наш модуль секретов для синхронизации базы публичных ключей авторизованных пользователей при запуске. Альтернативно, ключ достаётся из LDAP в момент начала аутентификации.
А чем отличается "ключ из LDAP" от "сервер в AD"? Ну, кроме "православности"?
C>В Винде нет никакого способа сделать конструктивное (в математическом смысле) описание системы, по которому можно автоматически и детерминироавнно построить с нуля новый образ машины. В Линуксе такое было лет так 8-10 назад, когда в конторе стоял Один Большой Сервер и вокруг него бегал неувольняемый админ.
Просто удивительно, зачем тогда пилят какой-то Докер.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
C>>При образ зашивается найстройка PAM, которая использует наш модуль секретов для синхронизации базы публичных ключей авторизованных пользователей при запуске. Альтернативно, ключ достаётся из LDAP в момент начала аутентификации. S>А чем отличается "ключ из LDAP" от "сервер в AD"? Ну, кроме "православности"?
Протокол? Ничем. Фича в том, что не требуется Kerberos. Ну и можно любые механизмы доставки ключа использовать.
Например, в сильно безопасных сетях ключи синхронизируются путём втыкания "флешки" с защитой от записи.
C>>В Винде нет никакого способа сделать конструктивное (в математическом смысле) описание системы, по которому можно автоматически и детерминироавнно построить с нуля новый образ машины. В Линуксе такое было лет так 8-10 назад, когда в конторе стоял Один Большой Сервер и вокруг него бегал неувольняемый админ. S>Просто удивительно, зачем тогда пилят какой-то Докер.
А Докер как раз и построен на конструктивных описаниях. См.: Dockerfile.
Здравствуйте, Cyberax, Вы писали: C>Например, в сильно безопасных сетях ключи синхронизируются путём втыкания "флешки" с защитой от записи.
Так из флешки или через LDAP?
C>А Докер как раз и построен на конструктивных описаниях. См.: Dockerfile.
Не, докер построен на image. А dockerfile — это один из 2х способов построения image.
В винде есть ндцать способов построения того, чего нужно. Вы же не думаете, что та же МС разворачивает свои рабочие станции при наёме сотрудников вручную?
Если вам очень хочется поизвращаться и вместо того, чтобы клонировать VMки из шаблона заставлять сервер выполнять пошаговые инструкции — скриптуйте всё в PowerShell.
Я затрудняюсь найти какую-нибудь особенность конфигурации винды, которую ну никак-никак нельзя заскриптовать через PowerShell.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
