Comments 52
Делать бэкап на локальные диски? Месье ищет приключений на свою пятую точку.
Тратить место на NVMe на ОС которая загружается 1 раз в полгода (да обьем небольшой, но зачем)?
512Gb на SSD для рабочих файлов CAD — это может быть маловато, но нужно смотреть конечно по факту.
Как я понимаю, своп ОС на том же SSD где и рабочие файлы или своп отключен?
P.S. и конечно сам NVMe дектопный — при росте нагрузке он будет сильно «тормозить», и хотя ресурс его 600TBW — нужно его мониторить — так как на сложных проектах и работе нескольких человек, можно легко иметь пару терабайтов перезаписи в день.
Хм. Я конечно ещё не мучал 2019, но 2016 мне преподнёс большую каку, когда я пробрасывал в гиперв, похожий видео адаптер, для работы с разным графическим по. Всё было сднлано5, рдп настроено, я довольный лёг спать… Утром звонок, а че рдп не работает? Я как? Так второй заходит ющер и первый вылетает. Несколько часов гугления и я нахожу, что адаптер в сессию пробрасывается только одну… Убирпешь проброс, пускает много юзеров, включаешь, только одну сессию. И когда поыиксят хер знает поыиксили в 2019?
Но зачем через Hyper-V? Просто 2019 на железо, ведь в VM вы всё равно нормально все ресурсы не прокинете — чем нибудь не пожертвовав. К тому же производительность однозначно может пострадать, то зачем нам виртуализация? Чтобы повесить всё на один ресурс? Мне кажется это немного извращенным, потому как некоторые вещи лучше не виртуализировать, и графический сервер один из таких случаев.
ilkman, вероятно зависит от драйвера видеокарты.
Пришлось делать интерпрайзовые 8.1 в которые этот адаптер пролезает как хост машину- никаких RDP
Что-то я не понял из комента, что и как вы реализовали? Если нужны именно VM с 3D видеокартой? то смотрим в сторону адаптеров с V-GPU, можно даже бу найти. Обыкновенные quadro прокидываются только в одну VM, а в остальные никак не распараллелить.
Делать бэкап на локальные диски?
это не совсем бекап в полном смысле этого слова — просто потенциально у нас есть точка отказа — это nvme, то в бекап попадают первоначальный образ системы и текущие рабочие файлы пользователей — это текущая временные файлы и локальные наброски за 1-2 дня — информация некритичная, в общую систему не попадает, но лучше ночью забекапить. Основная инфа — та что в приложении, то сохраняется всегда на сервере и часто синхронизируется с локальным кешом, так что это некритичный бекап рабочей станции, но для идеала — чтобы в случае отказа nvme ничего не пропало — инкрементно бекапим.
512Gb на SSD для рабочих файлов CAD — это может быть маловато
полностью согласен — но мне порезали бюджет после согласования
Как я понимаю, своп ОС на том же SSD где и рабочие файлы
Да на том же, на очень редкий случай если будет перелимит по памяти — то хотя бы не будет диких тормозов при работе, но жалоба возникнет и тогда просто докупим памяти.
конечно сам NVMe дектопный
в ту сумму ничего получше и понадежней не влазило. Сам люблю в серверы только серверное — но такова реальность, что приходится изголятся — одно радует что ssd самсунг еще ни одного отказа не было из нескольких десятков штук.
можно легко иметь пару терабайтов перезаписи в день
там такого объёма нет, но спасибо что обратили внимание, немного поправлю статью — добавлю этот момент.
RAID это не про надёжность, это про доступность. Схватите шифровальщика и не будет ни инфы ни бекапов
Raid это как раз надежность — накрывается один диск система работает дальше, ставим в RAID на замену и массив восстановлен. Если без RAID з резервированием(именно это имеется ввиду) что-то выходит из строя, то не факт, что сможете восстановить не только работу (доступность), но и данные (надежность). А про шифровальшик — это безопасность.
Часто аппаратная часть далеко не самая затратная составляющая… обыкновенно в сеансе RDP эти программы запускаются без проблемНе знаю в каких CAD\CAE-приложениях работают ваши инженеры, но весь виденный мною софт лицензировался по количеству пользователей и имел «перехватывающие» лицензии. т.е. пофигу где и на чем вы запускаете приложение, лишь бы не более n-копий одновременно.
Второй момент, выбор P2200. Это конечно мощная, но все же сингловая карта, отсюда не понятно, как она будет балансить нагрузку от нескольких пользователей. Да вы и сами пишите, что:
задействуют 100% ресурсов — то наше решение не подходит, так как другие пользователи в эти периоды не смогут нормально работать
По этому надо не страдать фигней, а ставить, то что из коробки поддерживает vGPU, умеет разделять ресурсы и вообще разрабатывалось для «Virtual Data Center Workstation»:
Тем более, сравниваете вы ее с P620, на которой имею удовольствие работать. Не знаю какой САПР вы используете, но Inventor в 3-4к деталей вызывает в ней лаги, и упирается она не в память =). Есть мнение, что какая-нибудь 1030\1060 даст примерно такой же или лучший результат. Найду адекватный тест, обязательно проверю. Т.е. проще взять сервак и навтыкать туда видях =)
Третий момент, если я правильно понял, то вы использовали обычный терминальный сервер, а не набор виртуальных машин. Т.е. в теории один пользователь, может положить все? Чем обусловлен такой выбор?
Инженеры, они такие, ленивые товарищи и любят автоматизировать всякие расчеты, блоки, схемы и прочие графики. Т.е. привет скрипты, VB(A) и прочие штуки с dwg.ru Тут два пути или запретить, но тогда прощай автоматизация и ускорение проектирования, или разрешить, но тогда прощай секьюронсть.
Четвертый момент, точка отказа. У вас сейчас тока отказа это сервер, на котором все данные. Предположим пожар в здании, ОБЭП или поломка мат.платы — все, 10(или сколько там у вас людей) человек будут сидеть без работы. Пока закажите, пока деньги найдут, пока приедет. Чтобы этого избежать надо иметь второй сервер хотя бы в холодном резерве. В случае использования отдельных рабочих станций, суммарный процент отказа выше, но за счет коэффициента одновременности простой меньше. И кстати,
А игровые мамки от силы работают 3-5 лет и даже процент поломки во время гарантийного срока у некоторых превышает 5%. А наш сервер от супернадежного бренда CISCOРебята из трассира (кто знает тот поймет) с вами не согласятся (см. фоточки вида сзади) Второе, заявленный срок мат.платы живут только потому, что устаревают.
Открою секрет, с серверами примерно то же самое, мы в 2016 брали под проект вот этот самый 2хE5-2620 v2, проект не пошел и сервак лежал на складе, решили мы в 2020 году собрать стенд из двух таких серверов (требовалось полная идентичность оборудования) и… внятное наличие есть на али и ебей (читай только БУ). А камню то «всего» 7 лет. Т.е. через 3-4 года все это превратиться в тыкву. Тем более что САПРы обновляются и начинают использовать всякие AVX 512. Опять таки не знаю какой САПР используете вы, но тот же Inventor требователен к частоте, т.е. лучше иметь 4 ядра по 3.7 чем 8 по 2.1 Третье, хотите надежное железо в пользовательском сегменте см. железо с поддержкой vPro(или во что оно сейчас там вылилось), MTTF\MTBF и прочие железо для бизнеса, нафига смотреть игровой сегмент?
Пятое, UDP-канал через VPN у MS эпизодически падает. Х.з. почему, но картинка фризится. Может этому способствует наш IPS\IDS-экран, но в интернетах полно вопросов «че делать то?» Причем падает он именно при использовании 3D.
Мы в свое время сделали вывод нормальный сервер (около 250-500 т.р.)+тонкие клиенты(по 20-30к.) будут стоить сопоставимо с отдельными граф. станциями, на топовом (на тот момент i7\16 Гб\512 SSD+1Тб НЖМД+2х24"). Считали для 10 раб. мест.
Плюсы:
-Гарантированное разделение ресурсов
-Независимость (при желании каждому можно дать административные права на его ПК под личную ответственность)
-Масштабируемость (в зависимости от САПРа кому ОЗУ побольше, кому ЦПУ побыстрее)
-Обновляемость, не хватает P620? Выкинули поставили P1000. Кончилось место на HDD — вот тебе второй.
Минусы
-Нужен нормальный администратор
-Нужен централизованный сервер для хранения бэкапов
-Раздать всем VPN и настроить каждому свой RDP
А игровые мамки от силы работают 3-5 лет и даже процент поломки во время гарантийного срока у некоторых превышает 5%. А наш сервер от супернадежного бренда CISCO
Ребята из трассира (кто знает тот поймет) с вами не согласятся (см. фоточки вида сзади) Второе, заявленный срок мат.платы живут только потому, что устаревают.
Более того, если игровой (да любой, на самом деле) ПК убрать из офисного угла и поместить в серверную, где стабильные параметры окружающей среды (температура, влажность), гарантированное стабильное питание, да и просто более трепетное отношение к оборудованию — он вполне себе проживёт десятки лет.
Кстати, а какого года выпуска ваш сервер?
если игровой (да любой, на самом деле) ПК убрать из офисного угла и поместить в серверную
вы в курсе что многие производители создают запланированное устаревание (и поломки аккурат после гарантийного срока) розничных продуктов? Даже если производитель это делает ненамеренно, но часто ради экономии многие закрывают глаза на установку компонентов со сроком службы чуть более гарантийного срока. Причем для корпоративного и серверного сегмента качество может отличаться на порядок или даже на два. Слишком много повидал таких игровых компонентов, причем дело почти всегда не в кондюках, а в чем либо более сложном. Причем игровые компоненты работают всегда на грани своих возможностей, что значительно уменьшает срок их службы.
Кстати, а какого года выпуска ваш сервер?
сервер вроде 2015
Я писал про то, что «атмосфера в офисе» не способствует длительной жизни любых компонентов.
И сервер, стоящий в кабинете рядом с обычным ПК, проживет значительно меньше своего аналога в серверной.
И ПК из «корпоративного сегмента» тоже дохнут быстрее, если допустить до них юзеров )
Я тоже видел сервак в кладовке. Он умер через 6 лет (не помню, материнка или бп, но заменить тогда было не так легко). А ещё видел самосбор, который пашет уже лет 12. Буду ли я на основании этих двух случаев всем рекомендовать самосборы? Нет, конечно.
Никто не говорил, что сервера менее надёжные, чем бытовые. Я писал, что в условиях серверной техника проживёт дольше.
Тем более, сравниваете вы ее с P620, на которой имею удовольствие работать. Не знаю какой САПР вы используете, но Inventor в 3-4к деталей вызывает в ней лаги, и упирается она не в память =). Есть мнение, что какая-нибудь 1030\1060 даст примерно такой же или лучший результат. Найду адекватный тест, обязательно проверю. Т.е. проще взять сервак и навтыкать туда видях =)
Не прокатит. GeForce в RDP не работают и в виртуалки не пробрасываются (если точнее то не включаются драйвера). В Linux (kvm) вопрос решается, а вот в Винде — вроде как нет.
Почему RDP а не виртуалки — а как вы предлагаете одну железку расшарить между несколькими виртуалками? а карты где работают виртуальные gpu каких-то безумных денег стоят (по сравнению не только с бытовым сегментов, но и с квадрами). Квадры в RDP работают вполне себе нормально.
Не совсем понял вас, что значит сингловая карта и почему квадра является такой. Если с точки зрения количества клиентов — то фигня. даже на бытовом сегменте можно нагрузить кучей задач (пока памяти хватает). Если нагрузка упрется в 100% по GPU, ресурсы будут примерно равномерно распределяться по задачам.
Так что предложенное решение с точки зрения использования GPU видится вполне приемлемым.
GeForce в RDP не работают
У нас у одного из инженеров стоит GTX 900-какая-то. И он прекрасно работает из дома.
Почему RDP а не виртуалки — а как вы предлагаете одну железку расшарить между несколькими виртуалками?Так как это предлагает делать NVIDIA при помощи vDWS, GRID и GRID vApps.
Если у вас нет денег на такие решения, то нафига ползать по столбам? Проще и надежнее вкатать отдельные графические станции.
То что получилось у автора это называется рендер-сервер. Обычно в него кидают куском тяжелой работы и идут спать, утром забирают результат. Но работать на таком нафиг-нафиг.
Если у вас нет денег на такие решения, то нафига ползать по столбам? Проще и надежнее вкатать отдельные графические станции.
Не попробуете — не узнаете, в том коллективе очень довольны — ведь могут работать отовсюду и часто в другой стране. В статье не описано, но перед этим на одном заводе для конструкторов было уже запущено 5-6 таких решений, но только на мощных ПК. Все особенно когда на карантин всё закрыли, подключились по RDP удаленно и продолжили работать в обыкновенном режиме, причем никаких рекламаций от более чем 30 человек вообще не поступало. А ведь знаете, что конструкторы народ привередливый — и когда нет жалоб — это серьёзный показатель. Просто меня очень радует, что решение по цене немного дешевле графической станции, но по качеству и масштабируемости её превосходит, поэтому и статью написал, чтобы и другие в похожей ситуации могли воспользоваться таким способом, особенно в условиях тотального уменьшения финансирования и закрытия на карантин.
Не знаю в каких CAD\CAE-приложениях работают ваши инженеры
в основном Creo, и немного Invertor.
но весь виденный мною софт лицензировался по количеству пользователей
в Creo привязывается к сетевухе, Invertor я не знаю как там лицензировали, я в этом не участвовал, но родительская компания работает в Inventor-е. Но как минимум 1 пользователь Inventor работает иногда совместно с пользователями Creo, и всё без лагов, правда думаю что в инвенторе там не будет 3-4k деталей, но в крео 5-7 тисяч.
Не знаю какой САПР вы используете, но Inventor в 3-4к деталей вызывает в ней лаги, и упирается она не в память =)
Скорее всего упирается в логику и проц и очень зависит от правильной методики работы. Ещё в далеком 2008 году на сборках 3-7 тисяч деталей был тормоз на дешевых видяхах, но после замены на nvidia 9600 забыли о такой проблеме. Поэтому и написал что мощность видях выросла в десятки раз, а реальная потребность выросла максимум в 1,5-2 раза. Сомневаюсь что при правильной методике работы будут какие либо тормоза. Ведь в Creo и других САПР есть главное и разные упрощенные представления, знаю что и в Catia и в Solid так есть. Но если работать всё время в главном представлении, то тормоза будут в любой проге и на любом оборудовании. И тормозит именно на проце, причем скорее всего все САПР проги для расчета геометрии и логики используют тупо одно ядро и только при загрузке модели могут подключать второе. Аппаратное ускорение используется только при 3D прокрутке и реальных ресурсов GPU там используется с гулькин нос — это вам не игры или кинематографические сцены, где нужно рендерить каждый из десятков тысяч листочков и травинок. Поэтому тормозов видяхи начиная с 2008 года и 9600 nvidia я не встречал. И p620 и p1000 и p2200 легко справляются с нагрузкой от 4-5(p620) до 8-10(p2200) — протестировано в Creo и Solid со сборками 3-8 тисяч деталей. Табличку что вы привели она для vGPU — я так понимаю для облачных систем и прочих виртуальных машин и примочек. А в моем случае никакой виртуализации не используется и система справляется прекрасно.
но Inventor в 3-4к деталей вызывает в ней лаги
открою вам секрет, много зависит от уровня проги. Нам представители Солида все рассказывали, что нам нужно купить какой-то безумно дорогой комп, чтобы на 5-7 тисячах не тормозило — такой комп купили, а при тестах в solidworks тормоза остались, хотя в Creo и Catia без тормозов абсолютно. И причем видяха там вообще никакой роли не играла — всё в проц упиралось. поэтому представители компании, чтобы втулить свою прогу будут рассказывать — ну вот будет у вас новое железо или только вышла новая версия в 3 раза быстрее работает — это профанации, чтобы поверили, что их прога подойдет. А на самом деле лидеры рынка уже более десятка лет спокойно справляются с гигантскими сборками при правильной методике работы.
Четвертый момент, точка отказа. У вас сейчас тока отказа это сервер, на котором все данные.
вы не так поняли этот сервер лишь рабочее место — CAD данные и прочее находятся в системе на других серверах. Поэтому потенциально, если этот сервер нагнется пользователи смогут с ноутов подключатся напрямую к системе, и продолжать работать пускай и в ограниченном (через слабость ноутов) режиме.
Пятое, UDP-канал через VPN у MS эпизодически падает
раньше было через openvpn ничего подобного не было ни разу. Теперь напрямую по RDP тоже без фризов. Но специально для вас расскажу фокус настройки RDP клиента — connection type:i:6 и networkautodetect:i:0 — интернет у большинства выше 10 мбит, то включаем тип соединения 6(локальная сеть 10Мбит и выше) и отключаем networkautodetect — ведь как раз этот networkautodetect катастрофически и надолго снижает вам скорость при даже небольшой потери пакетов- сервер тогда начинает максимально сжимать картинку и это создает очень ощутимый(до 1-2с) тормоз при работе, который пропадает в основном только после переподключения или перезагрузке. Также многие работают через Wifi и даже usb шнурок -там надо отключать энергосбережение через диспетчер устройств — тогда скорость растет на порядок.
Третий момент, если я правильно понял, то вы использовали обычный терминальный сервер, а не набор виртуальных машин. Чем обусловлен такой выбор?
в коменте выше люди уже так пробовали, но без специализированного решения — как в вашем случае, другой метод не пройдет. А инженерам объяснить довольно просто — там через диспетчер всё видно, кто насколько нагружает, и САПР проги при обыкновенной работе более одного ядра не грузят. А если кто хочет расчеты делать, то пожалуйста — есть ночь и выходные считай сколько хочешь.
P.S. Мой метод абсолютно рабочий — работает в трёх местах на 6-7 машинах разной мощности от мощного ПК до сервера в статье, в Creo, Solidworks и Inventor и очень больших сборках 5-8 тисяч деталей.
в Creo привязывается к сетевухе, Invertor я не знаю как там лицензировали, я в этом не участвовал, но родительская компания работает в Inventor-е.Мне кажется, вас больше должно интересовать не то, что к чему привязывается, а то, что написано в лицензионном соглашении.
Мне кажется, вас больше должно интересовать не то, что к чему привязывается, а то, что написано в лицензионном соглашении.
Я считаю, что тот кто соглашение подписывает тот пускай и интересуется, в данном случае это ответственность заказчика. В его оправдание лишь могу сказать, что PTC поступает очень некорректно, что даже во время пандемии не продает клиентам RDP feature к лицензии — ведь у многих офисы с лицензиями на компах закрыты. PTC конечно сделали так, что можно домой перенести лицензии, но у скольких людей дома или на ноуте есть аппаратная начинка для полноценной работы с Creo? Но это все лишь частный случай, в большинстве случаев лицензии выделяются на пользователя или на устройство, если на устройство — то мы значительно экономим, если на пользователя — то остаемся при своих(ведь до этого же эти пользователи как то работали?). PTC нужно пересмотреть свою дойную политику(только аренда на год, без бессрочных лицензий, запрет на продажу RDP feature к лицензии) — так как знаю уже много случаев, когда из-за такого жадного отношения многие перешли на более слабые решения конкурентов, но с бессрочными лицензиями.
- Анализ технических требований проведен не был. Возможно, какие либо тесты и погоняли, получили даже какие-то циферки для хвастовства у кого длиннее. Однако, достаточно открыть системные требования на Inventor или соответствующую ветку на Creo. И обнаружить, что и то и другое крайне плохо работает в многопоточности и ЦПУ рекомендуется от 3.0 ГГц. А вы им 2.1 вкорячиваете, т.е. по минималке. Далее 2620v2 имеет ВСЕГО 6 ядер (итого 12) т.е. у вас по 1 чистому ядру на пользователя в лучшем случае. Наймут еще одного инженера и чего делать будем? Впрочем ладно, 2020 год, у любого инженера помимо САПРа в фоне работает еще пара-пятерка приложений — PDF c даташитами, браузер с тем и же даташитами, эксель\ворд с ИДП расчетами и вы предлагаете это все вертеть на 1 ядре с HT? Как там хром, ютуб открывает? Хотя, да у вас же пул ресурсов общий, пользователи пусть сами разюираются (об этом ниже в п.2)
Про выбор видеокарты писал выше. P600\P620 это начальный уровень и упереть ее в вычислительную мощность можно 100\200 деталями в том же Inventor 2015 (самолично делал). Вы видимо со своими инженерами не общались. Потому что упирается оно как раз таки в скорость ядра ГПУ при вращении моделей. Впрочем, ладно, сложно оценивать потребность людей не зная задач — может у вас там сборки из 3х деталей (хотя зачем вам тогда вообще квадра?)
только вышла новая версия в 3 раза быстрее работает — это профанации, чтобы поверили, что их прога подойдет.
Бред сивой кобылы. Переезд с 12 на 15 инвентор был просто небом и землей, с 15 на 20 аналогично. И это не касаясь функционала, багов, поддержки новых стандартов и прочих ништяков — что в общем то происходит повсеместно в ПО. Нет, есть маленькая кучка олдов которые до сих пор ноют про быстродействие в ХП и офис 2003 без рибона.
Вы сами попадаете в ловушку — не использовать новое ПО потому, что тормозит, а тормозит оно потому что вы вкорячиваете устаревшее железо без поддержки новых стандартов (я писал про AVX), которое это самое ПО использует. Ну как бы порочный круг. Вот только страдают от этого инженеры, чей рабочий труд в общем то вас и кормит. Зачем ставить оборудование которое заведомо старо и де-факто уже превратилось в тыкву? — вопрос который мне не понятен. - Цель создания\обновления любой системы это решение конкретных проблем и, что самое главное, НЕ создание новых. А вы просто взяли и создали людям проблему с не разделяемостью ресурсов и переложили ответственность с себя.
Я просто физически ощущаю эти крики по офису:
-**ля, Петрович, ты опять рендер\сборку\<наименование операции> запустил! У меня все тупит.
-Мне срочно надо, сегодня отправлять.
-Да ты з****.
Даже тест был такой в советское время — загоняли команду в душ с ограниченным потоком горячей воды и смотрели за какое время они смогут договориться и не подраться.
Это с точки зрения аппаратного обеспечения. Про программное писали выше\ниже — вдруг кому шаблон листа потребуется изменить, и окажется, что у САПРа одна БД на всех. А вдруг кому обновить потребуется, а другим необходимо будет легаси?
- Вот чтобы такой фигни не было и не стрелять себе в ногу, и придумали VM\VDI. Так вот, пару лет назад для нормальной работы требовались решения по виртуализации на Citrix или VMWare. Что как бы нефигово раздувает бюджет, hyper-v в 12\16 сервере тупо не умел этого делать. VM-ки хорошо масштабируются, бэкапятся и резервируются и что самое главное НЕ мешают друг-другу!
Если резюмировать все вышесказанное, то ситуация выглядит так — у нас было 100к, модернизировать машины не хотелось, а хотелось поиграться с настоящим сервером (никогда не видели!). Вариант 2: руководство денег на модернизацию парка не давало, а вот на сервер выбить удалось.
Из всех возможных вариантов — аппаратной, программной части, системы архивирования и резервирования выбраны худшие варианты. Такое ощущение, что САПР с 1С перепутали.
Могли же просто на i3 (оно в базе от 3+ ГГц) начать собирать станции — давайте будем откровенны 9100F+Quattro620+16 Гб ОЗУ+256 SSD+1.0 HDD, можно уложить в 35 к. А то и в 30 если поставщики нормальные или поиграться параметрами и убрать скажем SSD\HDD\8Гб ОЗУ). И это все новое, свеженькое из магазина, лет на 5 хватит без проблем, с возможностью апгрейда и расширения.
То что получилось у вас можно назвать «рендер-сервером». Кинули кусоком тяжелой работы и пусть он там шуршит. Но для ежедневной разработки в свой отдел я бы такую хрень не принял бы не в жизнь — тут очевидно или необходимо увеличивать бюджет или upgrade-план составлять на ближайшие 2-3 года.
Я понимаю, что ви защищаете свое — очень дорогое но аналогичное решение "Мы в свое время сделали вывод нормальный сервер (около 250-500 т.р.)+тонкие клиенты(по 20-30к.)", которое всем впаривают вместо более приземленного по цене решения. Возможно для вашей программы Inventor — это единственно подходящее именно ваше решение, но что-то мне кажется — что вы немного лукавите, исходя из того что Inventor на моем решении спокойно работает.
Анализ технических требований проведен не был.
все технические требования я уже за 15 лет как вживую опробовал и сам могу рекомендации писать для Creo и Solidworks, 3ГГц это ни о чем — в 2005 тоже 3ГГц процы были и потом сборки выросли мы их на core 2 duo 1.3-1.8Гц поменяли так сразу все тормоза пропали.
Далее 2620v2 имеет ВСЕГО 6 ядер (итого 12) т.е. у вас по 1 чистому ядру на пользователя в лучшем случае. Наймут еще одного инженера и чего делать будем?
Рассмешили, вы в курсе что в среднем вы среднем используете лишь 15-30 процентов одного ядра при работе? И пользователь может интенсивно работать только с одной прогой, а все остальные в фоне и потребляют минимум? К тому же почти всю не CAD работу в основном выполняют на локальном ПК или ноуте. И в статье с самого начала написано "поменять процессоры (в нашем случае шестиядерные E5-2620 на десятиядерные Xeon E5 2690 v2)". E5 2690 v2 легко найти по 150-200$.
Про выбор видеокарты писал выше. P600\P620 это начальный уровень и упереть ее в вычислительную мощность можно 100\200 деталями в том же Inventor 2015 (самолично делал). Вы видимо со своими инженерами не общались.
Во первых P2200. Во вторых учитывая подход к разработке программ в Autodesk, то я уже лет 10 вообще стараюсь ничего общего с их продуктами не иметь. А если в 100/200 деталей у вас тормоз, то все конструкторы других полноценных программ вас засмеют, ведь еще в далеком 2008 еще в ProE на компах Core2 duo/8ГБ/9600GT сборки на 7k летали, а в CATIA так вообще там даже с зеркальным рендерингом(пробовали для прикола) такие сборки спокойно работали.
Переезд с 12 на 15 инвентор был просто небом и землей, с 15 на 20 аналогично.
это потому что изначально программа работала шлаково, в CAM/CAE высокого уровня всё изначально работало как надо, на одном заводе откуда я уволился ещё 2011 году, после меня никто уже больше ничего нового не внедрял и не ставил — там до сих пор успешно работают с изделиями в 7-10к деталей в proE 4.0
Вы сами попадаете в ловушку — не использовать новое ПО потому, что тормозит, а тормозит оно потому что вы вкорячиваете устаревшее железо без поддержки новых стандартов (я писал про AVX)
я всегда ставлю всё новоё и все обновления, но уже неоднократно вам писал, что у нас часто людям впаривают программу не того уровня, что необходимо им для работы. В моем случае навязчиво в нескольких конторах впаривают Solid, в котором ничего сложнее газонокосилки лучше не разрабатывать (сотни раз проверено и даже на сайте Solid у клиентов нет сложнее изделий более 3к). И расставят пальцы веером будут вам про AVX-ы шмиксы лапшу вешать.
Цель создания\обновления любой системы это решение конкретных проблем и, что самое главное, НЕ создание новых. А вы просто взяли и создали людям проблему с не разделяемостью ресурсов и переложили ответственность с себя
Абсолютно противоположно реальной ситуации пишете. Уже в третий раз вам пишу — решение опробовано и работает уже 3-4 года, только до этого работало для 3-4 пользователей, а тут для 8-10. К решению описанном в статье именно сами конструкторы были инициаторами, потому как решение им очень зашло.
Про программное писали выше\ниже — вдруг кому шаблон листа потребуется изменить
это вы батюшка совсем уж отстали от жизни, все шаблоны и прочее должны в нормальной PDM/PLM храниться и должны обговариваться в коллективе перед созданием новых.
Если резюмировать все вышесказанное, то ситуация выглядит так — у нас было 100к, модернизировать машины не хотелось, а хотелось поиграться с настоящим сервером (никогда не видели!).
Посмеялся от души. Ещё 2011 в моем ведении было 2 ЦОДа — один основной и один резервный(с 64 серверами fujitsu py bx920 s2) и 14 комутационных. Если честно, то в моих словах для вас есть много фишек, которые вам стоило бы взять на вооружение или хотя бы обдумать. Но если вы настроены предвзято, то предлагаю прекратить дискуссию.
на моем решении спокойно работает.
У меня дома на rpi3 вертится хоумпейдж с примерно таким кодом:
<img src="gif/<?php echo rand(1,9)?>.gif">и знаете, тоже все работает, целых два года! Это дает право говнокодить в продакшене и собирать (реверс-)прокси\веб-сервера на rpi?
в 2005 тоже 3ГГц процы были и потом сборки выросли мы их на core 2 duo 1.3-1.8Гц поменяли так сразу все тормоза пропали.
И расставят пальцы веером будут вам про AVX-ы шмиксы лапшу вешать.
Ну в принципе да, дальше просто не о чем говорить.
в среднем вы среднем используете лишь 15-30 процентов одного ядра при работе?
А мужики то и не знают! (С)
Могли же просто на i3 (оно в базе от 3+ ГГц) начать собирать станции — давайте будем откровенны 9100F+Quattro620+16 Гб ОЗУ+256 SSD+1.0 HDD, можно уложить в 35 к. А то и в 30 если поставщики нормальные или поиграться параметрами и убрать скажем SSD\HDD\8Гб ОЗУ). И это все новое, свеженькое из магазина, лет на 5 хватит без проблем, с возможностью апгрейда и расширения.
лет 5 как 32ГБ ОЗУ не хватает для тех конструкторов, для основной работы 32ГБ может и хватит, но 1-2 раза в недельку необходимо 40-60ГБ для основной сборки. В вашем решении(нормальный сервер (около 250-500 т.р.)+тонкие клиенты) так на 8-10 конструкторов нужно было бы минимум 512ГБ(~2700$) + сервер (2500$-3000$) итого около 6К$, в моем решении 1435$ все конструктора довольны и спокойно работают, а это главный результат. В вашем решении большим минусом есть, что память и ресурсы выделяются отдельно на каждого пользователя и используются абсолютно неоптимально и кпд в лучшем случае 20-30%, причем если пользователь вышел за лимит, у него будет конкретный тормоз. В моем случае КПД будет 70-80% и перелимит на пользователя не возникнет.
сопоставимо с отдельными граф. станциями, на топовом (на тот момент i7\16 Гб\512 SSD+1Тб
Там у тех пользователей ноуты с такими параметрами и а для многих задач нужно 20-50ГБ ОЗУ, поэтому им и нужен был для больших сборок этот графический сервер. Судят по результату — и мой результат уже 3-4 года как такой недорогой подход к решению поставленных задач оправдал себя на 100%, а в условиях пандемии так вообще по соотношению цена/100%_решение_поставленных_задач пока не имеет себе равных. Все ваши кажущеюся минусы моего решения абсолютно ничтожны на фоне его 7-ми успешных реализаций для более 30 конструкторов и для работы каждого со сборками более 7К деталей.
С самого начала у меня не было уверенности, что это 100% рабочее решение, так как на любом этапе, начиная со сборки заканчивая установкой, запуском и корректной работой приложений можно было застрять без возможности продолжить, поэтому про сервер я договорился, что его в течении пару дней можно будет вернуть, а другие компоненты можно использовать в альтернативном решении.
Отличная идея — сначала что-то купить, а потом проверять совместимость.
Посмотреть на сайте характеристики, compatibility list, спросить у вендора? Не, у нас так не принято. Давайте просто купим, если «не взлетит», то часть вернём (бухгалтерия такое любит, да), а оставшееся — используем в другом решении. Хаем игровые самосборы, потом покупаем не самое подходящее оборудование, «подгибаем что-то на сервере»…
В вашем случае — взлетело, но подход в целом — эникейский. Абзац про проблему с soft-режимом это только подтверждает.
Ладно хоть, программную часть как бы проверили перед покупкой (хотя, учитывая выделение жирным соответствующего упоминания в статье, есть сомнения):
Но проверить, что нужное нам ПО работает по RDP нужно в самом начале и сделать это просто: пробуем зайти по RDP — если программа запустилась и работают все базовые программные функции, то и проблем с лицензиями скорее всего не будет. А если выдает ошибку, то перед реализацией проекта с графическим терминальным сервером, ищем удовлетворительное для нас решение проблемы.
Если не было технических проблем при запуске, это ещё не значит, что «проблем с лицензиями не будет», впрочем, как и других проблем:
— Лицензии могут быть привязаны к кол-ву пользователей — тогда вы нарушаете лицензию.
— Софт может некорректно работать при нескольких запущенных инстансах — стоит ему хоть в одном месте писать мусор или настройки не в пользовательский профиль/%temp%, а в что-то общеедоступное — вам потом будет очень весело отлавливать проблему; сюда же озвученную выше проблему безопасности
Операционную систему (желательно Windows server 2019 — там качественный RDP) устанавливаем вначале в Trial режиме, но ни в коем случае не evaluate (нужно потом переустанавливать с нуля). И только после успешного запуска решаем вопросы с лицензиями и активируем ОС.
Вот тут я бы предложил другой вариант: после всех экспериментов с настройками — всё снести и поставить с нуля. Вот так:
— во время экспериментов надо документировать все критичные настройки
— во время установки с нуля вы повторно выполняете минимально необходимые настройки (которые задокументировали на предыдущем этапе)
Это решает несколько проблем. После чистой установки:
— вы точно знаете, что «оно работает» не из-за того, что вы перебрали несколько версий драйверов и какие-то из них «наследили» в системе (было, например, такое — в одной версии была галка в настройках, в следующей её убрали из интерфейса — но, поскольку предыдущая версия записала значение в реестр, то настройка применялась, хотя через интерфейс её отключить было невозможно )
— вы не забудете о какой-то настройке, которую включили в ходе экспериментов, но потом оставили (пример — решение проблемы soft-режима)
— вам не надо будет заново искать нестандартные решения (Clover)
Спустя какое-то время или сервер умрёт или надо будет мигрировать на новую версию ПО или развернуть ещё один сервер — у вас будет чёткий алгоритм, что надо сделать для восстановления (да, быстрее восстановить из бэкапа, но он не всегда применим).
Мне нередко приходилось принимать работу после эникейшиков, поверьте, это будет очень весело (на самом деле нет) — разбираться, почему не загрузился сервер после смерти флешки с Clover'ом, если не знать об этом костыле.
Сейчас у вас есть эта статья, неплохо бы оставить где-то рядом с сервером ссылку на неё, чтобы те, кому потом это обслуживать, знали хотя бы о назначении этой флешки или об отредактированных политиках.
Отличная идея — сначала что-то купить, а потом проверять совместимость.
Разве в статье не описано, что так делать не надо? Перед тем начинать движения — внимательно проштудировал спецификации сервера — разъем pci 16х есть(видяха), pci 4x есть(nvme), по питанию и размерам тоже инфа была. Поэтому риск почти отсутствовал, но всё равно определенный мандраж был. Но я уже лет 15 так поступаю в разных IT сферах — всё время иду первопроходцем — успешно ставлю и настраиваю разные системы, иногда бывая первым, кто вообще это реализовал. Ведь "под лежачий камень вода не течет". И теперь — я от многих работ отбиваюсь, так как есть свои темы, которыми не хочу жертвовать. А в описанном случае реализация уж очень зашла клиенту когда началась пандемия. Чего в статье не описано — так это то, что уже перед этим было успешно настроено 6-7 мощных ПК, просто на базе сервера сделано впервые.
Если не было технических проблем при запуске, это ещё не значит, что «проблем с лицензиями не будет», впрочем, как и других проблем:
— Лицензии могут быть привязаны к кол-ву пользователей — тогда вы нарушаете лицензию.
— Софт может некорректно работать при нескольких запущенных инстансах — стоит ему хоть в одном месте писать мусор или настройки не в пользовательский профиль/%temp%, а в что-то общеедоступное — вам потом будет очень весело отлавливать проблему; сюда же озвученную выше проблему безопасности
Полностью согласен с вами — немного поправлю статью, чтобы осветить эти моменты, в моем случае всё уже было пару лет как успешно опробовано, поэтому риска не было.
Вот тут я бы предложил другой вариант: после всех экспериментов с настройками — всё снести и поставить с нуля. Вот так:
— во время экспериментов надо документировать все критичные настройки
— во время установки с нуля вы повторно выполняете минимально необходимые настройки (которые задокументировали на предыдущем этапе)
Зачем заново всё ставить? В драйверах есть опция "чистая установка" — только так и ставлю, а остальные моменты у меня уже давно выверены(и задокументированы) при установках и настройках серверов. "надо документировать все критичные настройки" благодаря этому и писал статью. Но рекомендация отличная — включу в статью.
Если кто то даст голос на публикацию, я напишу нормальную статью. Ввиду политики, статьи не пропускает администрация портала.
Архитектор с большим стажем и практическими навыками внедрения.
По теме много больших вопросов, так как ucs не подходят для GPU внедрений.
Возможно опишите подробней про планируемую статью — тогда может кто нибудь поможет вам. Интересно было бы почитать про внедрение архитектурных систем и программ.
По теме много больших вопросов, так как ucs не подходят для GPU внедрений.
на локальном рынке бу серверов выбор очень мал — поэтому "я его слепила из того что было". Но для такого маленького бюджета вышло просто замечательно. Скажу вам по секрету, но заказывали просто мощный комп, но по моей инициативе сделали реализацию на базе UCS вышло по параметрам в 1,5-раза лучше чем заказанный ПК.
Многие недальновидные админы (много раз уже сталкивался) —
Кхм, гуглим по Asrock rack. Напрю, мать X470D4U2-2T умеет и m.2 и 10Gbit\s и KVM
И главное — PCIE6: Gen3 x16 link (splittable in x4/4/4/4).
Для чего? А вот для этого — ASUS Hyper M.2 X16 PCIe 3.0 X4 Expansion Card V2, ASRock Ultra Quad M.2 Card или китаец Адаптер JEYI iHyper SSD 4x M.2 NVMe to PCIe Adapter (JP84A)
И будет очччень быстро )
Использовать без вирт-ции в 2020-м? Ну, я не знаю.
0. Качаем Proxmox VE.
1. Качаем Ventoy для установки proxmox (и не только) с флешки. После установки ventoy на флешку просто забрасываем .iso с прокмоксом на нее.
2. Вкл. в БИОС все, что касается вирт-ции — vt-x, vt-d, sr-iov (если есть)
3. Заходим в БИОС контроллера и откл. рейд. Нам нужны диски в сыром режиме.
4. Развертываем Proxmox на ZFS.
3. Подготавливаем гипер для проброса gpu — pve.proxmox.com/wiki/Pci_passthrough, pve.proxmox.com/wiki/PCI(e)_Passthrough, www.reddit.com/r/homelab/comments/b5xpua/the_ultimate_beginners_guide_to_gpu_passthrough, www.youtube.com/watch?v=_fkKIMF3HZw (читать комменты)
4. Создаем ВМ на q35 + uefi, устанавливаем ОС с использованием virtio drivers + guest agent.
5. Выключаем ВМ и создаем снепшот на всякий.
6. В настройках ВМ пробрасываем gpu в нее
7. Стартуем ВМ, устанавливаем драйверы на gpu как обычно.
8. PROFIT.
Если пробрасываем nvidia и виртуальная ОС падает в бсод, то ищем в гугле по фразе 'nvidia error 43 fix proxmox'
Касаемо бэкапов. Эконом вариант — бэкапить на отдельные диск(и), подключенные к гиперу (лучше несколько и собрать из них zfs-рейд прямо в gui proxmox-а). Proxmox пользует zstd для сжатия бэкапов — это оч быстро (сотни мегабайт в сек).
А если немного подождать, то можно будет пользовать и incremental backup с Proxmox Backup Server — forum.proxmox.com/threads/proxmox-backup-server-beta.72676/
При выборе обычных HDD не наткнитесь на SMR-диски. Для ZFS (и не только) они категорически не подходят www.servethehome.com/surreptitiously-swapping-smr-into-hard-drives-must-end/surreptitious-smr-hard-drive-swaps-must-stop-cover
Зы. Кто-нибудь опишите мне преимущества hyper-v перед открытыми продуктами (proxmox, ovirt, opennebula etc)? На кой его сейчас пользовать-то? Спасибо.
Использовать без вирт-ции в 2020-м? Ну, я не знаю.
На каждую VM мы выделяем определенный объём памяти, а решение с RDP сервером имеем общую память. Самой основной задачей в той компании — работа с большими объёмами 40-60ГБ ОЗУ(на пользователя). При работе 8-10 пользователей для хоста с VM нужно было бы где-то 640ГБ, и при этом весь этот объём большую часть времени простаивал бы, так как большие сборки каждый из пользователей загружает лишь изредка. А в решении с RDP сервером память общая, и в реальной работе всё происходит по след. сценарию — изредка любой из пользователей загружает большую модель ~40-60ГБ, поработает с ней часик, сохранится, закроет модель — память освободится. И случаев когда всем нужно работать с большой моделью на практике не бывает. Поэтому на всех пока с головой хватает объёмов 128ГБ, и в крайнем случае докупить ещё 64ГБ можно за 2-3 часа(если вдруг "горит"). А с VM кроме неразумного использования памяти, ещё много вылазит проблем особенно с пробросом в несколько машин одного gpu(нужны спец gpu за кучу денег).
На каждую VM мы выделяем определенный объём памяти, а решение с RDP сервером имеем общую память
Не выделяйте. Пусть у Вас будет единственная ВМ на гипере, если это критично.
Плюсы же:
1. Бэкапы ВМ с ротацией.
2. Снепшоты (можно и не выключая ВМ). Зачем? Да для того, чтобы вернуться к работоспособному состоянию ВМ после очередного
3. Возможность поднять рядом копию ВМ и тестировать на ней.
И т.д.
Повторюсь, что не использовать вирт-цию в 2020-м — это крайняя глупость. Накладные расходы на нее — мизерны, а профита — куча.
Автор статьи просто застрял в каком-то один-эсье 2008ого года.
а проблему с пробросом Gpu на несколько ВМ вас не смущают?
- Бэкапы ВМ с ротацией.
- Снепшоты (можно и не выключая ВМ). Зачем? Да для того, чтобы вернуться к работоспособному состоянию ВМ после очередного кривого «вторника обновлений» от MS
ставим veeam и все имеем без ВМ.
Каждая ВМ — отдельная ОС, забирает ресурсы и нужны доп лицензии в том числе и на очень дорогой софт.
Виртуализация ради виртуализации — это бред, никаких проблем не решает, а дополнительные создает. Когда успешно реализуете 5-6 таких решений на 5-10 пользователей 3D графики, то можете про это написать подробную статью на хабре и многие вам спасибо скажут. А пока скорее всего вы для графических пользователей подобного решения не реализовывали, и ваши аргументы чисто теоретические. А в моем случае реализовано уже 6-7 таких решений, которые успешно работают и причем даже никаких нареканий от пользователей нет — а это самый весомый показатель.
а проблему с пробросом Gpu на несколько ВМ вас не смущают?
Не смущает. Сейчас и CPU имеет интегрированное видео и мат платы имеют нес-ко разъемов PCI-e x16. Сколько возможно — столько и пробросим.
ставим veeam и все имеем без ВМ.
Что мешает поставить veeam в ВМ? И да, Veaam — это сущность, для к-ой нужна доп. машина с MS Windows на борту.
Каждая ВМ — отдельная ОС, забирает ресурсы и нужны доп лицензии в том числе и на очень дорогой софт.
Ответил в предыдущем сообщение.
Когда успешно реализуете 5-6 таких решений на 5-10 пользователей 3D графики, то можете про это написать подробную статью на хабре и многие вам спасибо скажут.
В чем проблема пробросить GPU в вирт. машину с терминальным сервером и пользовать 1:1 как на реальном железе?
Виртуализация ради виртуализации — это бред, никаких проблем не решает, а дополнительные создает
Вирт-ция — это удобно. Как минимум.
А в моем случае реализовано уже 6-7 таких решений
С вирт-цией плотно с 2006-го. Начинал с Citrix Xen, после были ESXI и Hyper-V, но пришел к KVM о чем нисколько не жалею.
Пользуйте и применяйте (пока не поздно) forum.netgate.com/topic/120102/proxmox-ceph-zfs-pfsense-и-все-все-все/109
а проблему с пробросом Gpu на несколько ВМ вас не смущают?А встройкины драйвера распаралелятся на несколько пользователей/ВМ?
Не смущает. Сейчас и CPU имеет интегрированное видео
аналогичный вопрос wertex78 уже задавали, но неудобные вопросы просто игнорирует. Как и вопрос с лицензиями на каждую ОС и софт в ВМ. Либо не понимает вопроса, либо нет ответа.
Для остальных ВМ будет использоваться виртуальный видео-адаптер гипервизора. Это в случае ОБЫЧНОЙ видеокарты.
Профессиональные видеокарты поддерживают vGPU (+ сервер должен уметь в SR-IOV).
habr.com/ru/company/cloud4y/blog/460627
docs.nvidia.com/grid/10.0/grid-vgpu-user-guide/index.html
www.vmware.com/files/ru/pdf/products/horizon/vmware-nvidia-grid-vgpu-FAQ.pdf
gridforums.nvidia.com/default/topic/8989/general-discussion/list-of-gpus-that-support-dda-in-server-2016-for-gpu-pass-through-in-hyper-v-vms
gridforums.nvidia.com/default/topic/8934
www.reddit.com/r/VFIO/comments/9enx3t/break_down_a_gpu_to_several_vms_sriov_options_at
Видео на эту тему www.youtube.com/watch?v=11Fs0NHgzIY
SR-IOV is a tech that lets several virtual machines share a single piece of hardware, like a network card and now graphics cards
Такая технология есть и у AMD (MXGPU) и у Intel (Intel GVT-g)
По сути, все равно что пробрасывать. Главное — это поддержка на уровне железа и ПО.
Драйвера же входят в ПО? Если они по какой-либо причине лишены такой функциональности, то и пробрасывать не будут?
У нвидия есть проблема error 43 при пробросе ОБЫЧНОЙ карты в ВМ. Ее надо «уговаривать» работать в вирт. среде. Поищите.
Если вы пробрасываете GPU в ВМ, то доступно оно будет только в этой ВМ..
наконец-то вы это признали
Профессиональные видеокарты поддерживают vGPU (+ сервер должен уметь в SR-IOV).
обыкновенные Quadro не поддерживают, там уже Nvidia Tesla и прочие. Но не факт, что самосбор у вас без проблем соберется, запустится и будет полноценно в 3D работать (цель полностью для каждого пользователя заменить графическую станцию).
Но насчет лицензий на ОС и софт, отвечу за Вас: да, придется отдельно покупать лицензии и на ОС и софт(десятки тисяч$) — зато мы гордо можем сказать — у нас Виртуализация и денег нам на это не жалко!
наконец-то вы это признали
Признал что? Что (пока) невозможно расшарить обычную видяху нескольким ВМ? Так я это и не отрицал. Для этого выше и отписал про проф. решения в этой сфере.
Но насчет лицензий на ОС и софт, отвечу за Вас: да, придется отдельно покупать лицензии и на ОС и софт(десятки тисяч$)
А устанавливая каждый раз софт на отдельное железо Win-лицензии покупать не надо? Чушь какая-то.
И какие «тысячи»? Proxmox покупать не надо, если не нужна отдельная поддержка и фичи лично для вас. Качай, ставь, пользуй.
Вы даже загуглить не смогли по поводу proxmox, hyper-v, esxi.
А устанавливая каждый раз софт на отдельное железо Win-лицензии покупать не надо? Чушь какая-то.
И какие «тысячи»? Proxmox покупать не надо, если не нужна отдельная поддержка и фичи лично для вас. Качай, ставь, пользуй.
Перед тем как комментировать статью, её нужно прочитать и понять. А ваши ответы все не по сути, а сплошной спам. Статья про RDP сервер и аргументы все изложены в ней, прочитайте её внимательно, а не спамьте рекламой решений, которые никоим образом не связаны с основной темой статьи. Про лицензии в статье написано, что очень дорогой графический или CAD/CAM софт часто лицензируется на устройство и при использовании на терминальном сервере можно сэкономить на количестве лицензий, а это иногда десятки тысяч $. Но судя по вашим ответам — вы даже заголовок статьи не внимательно читали, а сразу комментировать со своим спамом.
Обещают много вкусного (Deduplication, Incremental backups, Remote Sync, Compression with zstd, Encryption). Плюс можно поднять прямо на proxmox-хосте.
Пробуем )
А устанавливая каждый раз софт на отдельное железо Win-лицензии покупать не надо? Чушь какая-то.
И какие «тысячи»? Proxmox покупать не надо, если не нужна отдельная поддержка и фичи лично для вас. Качай, ставь, пользуй.
Перед тем как комментировать статью, её нужно прочитать и понять. А ваши не ответы все не по сути, а сплошная реклама рекламного агента сайта и программы. Статья про RDP сервер и аргументы все изложены в ней, прочитайте её внимательно, а не спамьте рекламой вашей низкосортной продукции и сайта.
Собираем сервер для графических и CAD/CAM приложений для удаленной работы по RDP на базе бу CISCO UCS-C220 M3 v2