Tworzymy serwer do aplikacji graficznych i CAD/CAM do pracy zdalnej przez RDP oparty na używanym CISCO UCS-C220 M3 v2

Tworzymy serwer do aplikacji graficznych i CAD/CAM do pracy zdalnej przez RDP oparty na używanym CISCO UCS-C220 M3 v2
Prawie każda firma ma obecnie obowiązkowy dział lub grupę pracującą w CAD/CAM
lub w zaawansowanych programach projektowych. Użytkowników tej grupy łączy poważne zapotrzebowanie na sprzęt: dużo pamięci — 64GB lub więcej, profesjonalna karta graficzna, szybki SSD, a także niezawodność. Często firmy kupują niektórym użytkownikom w takich działach kilka potężnych komputerów (lub stacji roboczych), a innym mniej wydajne w zależności od potrzeb oraz możliwości finansowych firmy. To standardowe podejście do rozwiązywania takich problemów, które dobrze działa. Jednak w czasie pandemii i pracy zdalnej, oraz ogólnie — takie podejście jest nieoptymalne, bardzo przesadne i skrajnie niewygodne w administracji, zarządzaniu i innych aspektach. Dlaczego tak się dzieje i jakie rozwiązanie idealnie spełni potrzeby w zakresie stacji graficznych wielu firm? Zapraszam do lektury poniżej, gdzie opisano, jak stworzyć funkcjonalne i niedrogie rozwiązanie, aby od razu zaspokoić kilka potrzeb, oraz jakie drobne szczegóły należy uwzględnić, aby pomyślnie wdrożyć to rozwiązanie.

W grudniu zeszłego roku jedna firma otworzyła nowe biuro dla małego biura konstrukcyjnego i postawiono przed nimi zadanie zorganizowania całej infrastruktury komputerowej, biorąc pod uwagę, że laptopy dla użytkowników oraz kilka serwerów już były dostępne. Laptopy miały już kilka lat i były to głównie konfiguracje gamingowe z 8-16GB RAM, które nie radziły sobie z obciążeniem płynącym z aplikacji CAD/CAM. Użytkownicy muszą być mobilni, ponieważ często konieczna jest praca poza biurem. W biurze dodatkowo do każdego laptopa kupowane są monitory (tak pracuje się z grafiką). W takich warunkach — jedynym optymalnym, ale ryzykownym dla mnie rozwiązaniem — jest wdrożenie potężnego serwera terminalowego z wydajną profesjonalną kartą graficzną i dyskiem NVMe SSD.

Zalety graficznego serwera terminalowego i pracy przez RDP

  • Na indywidualnych potężnych komputerach lub stacjach roboczych przez większość czasu zasoby sprzętowe nie są wykorzystywane nawet w jednej trzeciej i marnują się, tylko przez krótki czas są używane w 35-100% swojej mocy. Głównie wydajność wynosi 5-20 procent.
  • Jednak często sprzęt nie jest najdroższym elementem, ponieważ podstawowe licencje na oprogramowanie graficzne lub CAD/CAM często kosztują od 5000$, a jeśli dodamy rozszerzone opcje, to nawet od 10 000$. Zwykle te programy działają bez problemu w sesji RDP, ale czasami trzeba dokupić opcję RDP lub poszukać na forach, co wpisać w konfiguracjach lub rejestrze oraz jak uruchomić takie oprogramowanie w sesji RDP. Jednak aby sprawdzić, czy potrzebne nam oprogramowanie działa przez RDP należy na samym początku i zrobić to w prosty sposób: próbujemy wejść przez RDP — jeśli program uruchomił się i działają wszystkie podstawowe funkcje, to nie powinno być problemów z licencjami. A jeśli wystąpi błąd, to przed realizacją projektu z graficznym serwerem terminalowym szukamy satysfakcjonującego dla nas rozwiązania problemu.
  • Dużym plusem jest również wsparcie dla identycznej konfiguracji oraz specyficznych ustawień, komponentów i szablonów, co często jest trudne do zrealizowania dla wszystkich użytkowników komputerów. Zarządzanie, administracja i aktualizacja oprogramowania również przebiegają 'bez problemu'

W sumie jest wiele zalet — zobaczymy, jak to nasze prawie idealne rozwiązanie w praktyce się sprawdzi.

Budujemy serwer oparty na używanym CISCO UCS-C220 M3 v2

Początkowo planowano kupić nowszy i mocniejszy serwer z 256GB pamięci DDR3 ECC i 10GB ethernet, ale powiedziano, że trzeba nieco zaoszczędzić i zmieścić się w budżecie na serwer terminalowy 1600$. Cóż — klient zawsze jest mało wyrozumiały, więc dobieramy coś w tej cenie:

używany CISCO UCS-C220 M3 v2 (2 X SZEŚCIOJĄDROWY 2.10GHZ E5-2620 v2) 128GB DDR3 ECC — 625$
3.5" 3TB SAS 7200 z USA — 2×65$=130$
SSD M.2 2280 970 PRO, PCI-E 3.0 (x4) 512GB Samsung — 200$
Karta graficzna QUADRO P2200 5120MB — 470$
Adapter Ewell PCI-E 3.0 do M.2 SSD (EW239) -10$
Razem za serwer = 1435$

Planowano kupić SSD 1TB i adapter ethernet 10GB — 40$, ale okazało się, że nie mieli UPS dla swoich 2 serwerów, więc musiałem trochę zmniejszyć wydatki i kupić UPS PowerWalker VI 2200 RLE -350$.

Dlaczego serwer, a nie potężny komputer PC? Uzasadnienie wybranej konfiguracji.

Wielu niedoświadczonych administratorów (już wielokrotnie się z tym spotkałem) — dlaczegoś kupuje potężny (często gamingowy komputer), instalują w nim 2-4 dyski, tworzą RAID 1, dumni nazywają to serwerem i stawiają go w kącie biura. Oczywiście cały zestaw to 'mieszanka' wątpliwej jakości. Dlatego szczegółowo opiszę, dlaczego pod taki budżet wybrana została właśnie taka konfiguracja.

  1. Niezawodność!!! — wszystkie komponenty serwerowe są zaprojektowane i przetestowane do pracy przez ponad 5-10 lat. A grywalne płyty główne działają najwyżej 3-5 lat, a procent awarii w trakcie okresu gwarancyjnego u niektórych przekracza 5%. Nasz serwer pochodzi od niezwykle niezawodnego producenta CISCO, więc nie przewidujemy większych problemów, a ich prawdopodobieństwo jest znacznie niższe niż w przypadku stacjonarnego PC.
  2. Ważne komponenty, takie jak zasilacz, są podwójne, a w idealnym przypadku można podać zasilanie z dwóch różnych linii, a przy awarii jednego bloku serwer nadal działa.
  3. Pamięć ECC — obecnie mało kto pamięta, że pierwotnie pamięć ECC została wprowadzona do korekcji jednego bitu błędu, który występuje głównie w wyniku działania promieni kosmicznych, a przy pojemności pamięci 128GB błąd może występować kilka razy w roku. Na stacjonarnym komputerze możemy zaobserwować awarię programu, zawieszanie się itp., co nie jest krytyczne, ale w serwerze koszt błędu jest czasami bardzo wysoki (na przykład błędny zapis w bazie danych). W przypadku poważnego problemu musimy zrestartować serwer, co czasami może kosztować dziennej pracy kilku osób.
  4. Skalowalność — często zapotrzebowanie firmy na zasoby wzrasta kilka razy w ciągu kilku lat i w serwerze łatwo można dodać pamięć, wymienić dyski, procesory (w naszym przypadku z sześciordzeniowych E5-2620 na dziesięciordzeniowe Xeon E5 2690 v2) — w zwykłym PC praktycznie brak skalowalności.
  5. Format serwera U1 — serwery muszą być umieszczone w serwerowniach! i w kompaktowych szafach, a nie grzać (do 1kW ciepła) i hałasować w rogu biura! W nowym biurze firmy przygotowano osobno trochę miejsca (3-6 jednostek) w serwerowni, a jedna jednostka na nasz serwer była idealnie dopasowana.
  6. Zdalne: zarządzanie i konsola — bez tego normalna obsługa serwera do pracy zdalnej jest skrajnie utrudniona!
  7. 128GB RAM — w specyfikacji było napisane 8-10 użytkowników, ale w rzeczywistości będzie 5-6 jednoczesnych sesji — biorąc pod uwagę typowe maksymalne zużycie pamięci w tej firmie, 2 użytkowników po 30-40GB = 70GB i 4 użytkowników po 3-15GB = 36GB, + do 10GB na system operacyjny w sumie 116GB i 10% w zapasie (wszystko to w rzadkich przypadkach maksymalnego wykorzystania. Ale jeśli zabraknie, można dodać do 256GB w każdej chwili.
  8. Karta graficzna QUADRO P2200 5120MB — średnio na jednego użytkownika w tej firmie.
    W zdalnej sesji zużycie pamięci wideo wynosiło od 0,3 GB do 1,5 GB, więc 5 GB będzie wystarczające. Dane źródłowe pochodziły z podobnego, ale mniej wydajnego rozwiązania opartego na i5/64 GB/Quadro P620 2 GB, które wystarczało dla 3-4 użytkowników.
  9. SSD M.2 2280 970 PRO, PCI-E 3.0 (x4) 512 GB Samsung — do jednoczesnej pracy.
    8-10 użytkowników, potrzebna jest dokładnie szybkość NVMe i niezawodność SSD Samsung. Dysk ten będzie używany do systemu operacyjnego i aplikacji.
  10. 2x3 TB SAS — łączymy w RAID 1, używamy do dużych lub rzadko używanych lokalnych danych użytkowników, a także do kopii zapasowej systemu i krytycznie ważnych lokalnych danych z dysku NVMe.

Konfiguracja została zatwierdzona i zakupiona, wkrótce nastąpi moment prawdy!

Montaż, konfiguracja, instalacja i rozwiązywanie problemów.

Od samego początku nie miałem pewności, że to 100% działające rozwiązanie, ponieważ na każdym etapie, od montażu po instalację, uruchamianie i prawidłowe działanie aplikacji, można było utknąć bez możliwości kontynuacji. Dlatego umówiłem się, że serwer można zwrócić w ciągu kilku dni, a inne komponenty można wykorzystać w alternatywnym rozwiązaniu.

1 fikcyjny problem — karta graficzna profesjonalna, pełnoformatowa! +parę mm, a co jeśli nie wpasuje? 75 W — a co jeśli złącze PCI nie wytrzyma? I jak zapewnić normalne odprowadzanie ciepła tych 75 W? Ale się zmieściła, uruchomiła, odprowadzanie ciepła jest prawidłowe (szczególnie jeśli włączyć wentylatory serwera na wyższe obroty). Gdy ją instalowałem, dla pewności, żeby nic nie zwarło w serwerze, odgiąłem na 1 mm (już nie pamiętam co), a dla lepszego odprowadzania ciepła po ostatecznej konfiguracji ściągnąłem folię instrukcji z całej pokrywy, która mogła pogarszać odprowadzanie ciepła przez pokrywę.

2. próba — dysk NVMe przez adapter mógł być niedostrzegany lub system nie mógłby być na nim zainstalowany, a jeśli by został zainstalowany, to nie załadowałby się. Ku mojemu zdziwieniu Windows zainstalował się na dysku NVMe, ale nie mógł się z niego załadować, co jest logiczne, bo BIOS (nawet zaktualizowany) w ogóle nie chciał go rozpoznać do załadowania. Nie chciałem używać tymczasowych rozwiązań, ale musiałem — tutaj z pomocą przyszedł nasz ulubiony Habr i wpis. o uruchamianiu z dysku NVMe na systemach legacy. ściągnąłem. narzędzie Boot Disk Utility (BDUtility.exe)., stworzyłem pamięć USB z CloverBootManager zgodnie z instrukcją z posta, ustawiłem pamięć w BIOSie jako pierwszą do rozruchu i już uruchamiamy bootloader z pamięci USB, Clover pomyślnie rozpoznał nasz dysk NVMe i po kilku sekundach automatycznie z niego wystartował! Można było pobawić się w instalację Clover na naszym dysku raid 3TB, ale była już sobotnia wieczór, a pracy zostało jeszcze na dzień, bo do poniedziałku trzeba było albo oddać serwer, albo go zostawić. Pamięć rozruchowa została wewnątrz serwera, tam akurat był zbędny port USB.

Trzecie, prawie groźba niepowodzenia. Zainstalowałem Windows 2019 standard + usługi RD, zainstalowałem główną aplikację, dla której wszystko to zaczęło się, i wszystko działa wspaniale i dosłownie się rozkręca.

Wspaniale! Jadę do domu i łączę się przez RDP, aplikacja się uruchamia, ale odczuwam poważne opóźnienie, widzę w programie komunikat „włączony tryb soft”. Co?! Szukam nowszych i super profesjonalnych sterowników do karty graficznej, instaluję - efektu zero, nic nie dają też starsze sterowniki pod p1000. A w tym czasie wewnętrzny głos wciąż się drwi: „a mówiłem ci — nie eksperymentuj z nowościami — weź p1000”. A czasu — już dawno noc na dworze, z ciężkim sercem idę spać. Niedziela, jadę do biura — wkładam do serwera quadro P620 i również przez RDP nie działa — co jest, MS? Szukam na forach „serwer 2019 i RDP” — odpowiedź znalazłem prawie od razu.

Okazuje się, że ponieważ większość ludzi ma obecnie monitory o dużej rozdzielczości, a w większości serwerów wbudowany adapter graficzny nie obsługuje tych rozdzielczości — to przyspieszenie sprzętowe domyślnie jest wyłączone przez zasady grupowe. Cytuję instrukcję włączenia:

  • Otwórz narzędzie Edytor zasad grupy z Panelu sterowania lub użyj dialogu wyszukiwania w systemie Windows (klawisz Windows + R, następnie wpisz gpedit.msc)
  • Przejdź do: Lokalna polityka komputera -> Konfiguracja komputera -> Szablony administracyjne -> Komponenty systemu Windows -> Usługi pulpitu zdalnego -> Host sesji pulpitu zdalnego -> Środowisko sesji zdalnej
  • Następnie włącz opcję „Użyj domyślnego adaptera graficznego sprzętowego dla wszystkich sesji Usług pulpitu zdalnego”

Przeprowadzamy restart — wszystko działa doskonale przez RDP. Wymieniamy kartę graficzną na P2200 i znowu działa! Teraz, gdy jesteśmy pewni, że rozwiązanie jest w pełni operacyjne, doprowadzamy wszystkie ustawienia serwera do ideału, wprowadzamy do domeny, konfigurujemy dostęp użytkowników i inne, umieszczamy serwer w serwerowni. Testujemy przez kilka dni razem z zespołem — wszystko działa idealnie, zasoby serwera wystarczają z nawiązką, minimalne opóźnienie spowodowane korzystaniem z RDP jest niewidoczne dla wszystkich użytkowników. Wspaniale — zadanie wykonane w 100%.

Kilka kwestii, od których zależy sukces wdrożenia serwera graficznego

Ponieważ na każdym etapie wdrożenia serwera graficznego w organizacji mogą pojawić się nieprzewidziane trudności, które mogą stworzyć sytuację podobną do tej na obrazku z uciekającymi rybkami,

Tworzymy serwer do aplikacji graficznych i CAD/CAM do pracy zdalnej przez RDP oparty na używanym CISCO UCS-C220 M3 v2

na etapie planowania należy wykonać kilka prostych kroków:

  1. Docelowa grupa odbiorców i zadania — użytkownicy, którzy intensywnie pracują z grafiką i potrzebują sprzętowego przyspieszenia karty graficznej. Sukces naszego rozwiązania oparty jest na tym, że potrzeby użytkowników programów graficznych oraz CAD/CAM były zaspokojone z nawiązką ponad 10 lat temu, a obecnie posiadamy zapas mocy przewyższający potrzeby wielokrotnie. Na przykład, moc GPU Quadro P2200 wystarcza z nawiązką dla 10 użytkowników, a nawet przy braku pamięci wideo karta pobiera z RAM-u, i dla zwykłego dewelopera 3D takie niewielkie spadki prędkości pamięci są niewidoczne. Jednak jeśli w zadaniach użytkowników występują intensywne obliczenia (rendering, obliczenia itp.), które często wykorzystują 100% zasobów — nasze rozwiązanie nie nadaje się, ponieważ inni użytkownicy w tym czasie nie będą mogli normalnie pracować. Dlatego starannie analizujemy zadania użytkowników i aktualne obciążenie zasobów (przynajmniej w przybliżeniu). Zwracamy także uwagę na ilość zapisu na dysk dziennie i jeśli wynosi ona duży wolumen, dobieramy pod ten wolumen serwerowe SSD lub dyski Optane.
  2. W zależności od liczby użytkowników dobieramy odpowiedni zasobami serwer, kartę graficzną i dyski:
    • procesory według wzoru 1 rdzeń na użytkownika + 2,3 na system operacyjny, przecież i tak każdy w danym momencie nie korzysta z jednego lub maksymalnie dwóch (przy rzadkim obciążeniu modelu) rdzeni;
    • karta graficzna - sprawdzamy średnie zużycie pamięci wideo i GPU na użytkownika w sesji RDP i wybieramy profesjonalną kartę graficzną;
    • analogicznie podchodzimy do RAM-u i subsystemu dyskowego (teraz można nawet niedrogo znaleźć RAID nvme).
  3. Dokładnie sprawdzamy dokumentację serwera (na szczęście wszystkie markowe serwery mają pełną dokumentację) pod kątem zgodności z gniazdami, prędkościami, zasilaniem oraz wspieranymi technologiami, a także wymiarami fizycznymi i normami odprowadzania ciepła dodatkowych komponentów.
  4. Sprawdzamy prawidłowe działanie naszego oprogramowania w kilku sesjach RDP, a także pod kątem braku ograniczeń licencyjnych i dokładnie weryfikujemy posiadanie niezbędnych licencji. Rozwiązujemy ten problem przed pierwszymi krokami realizacji wdrożenia. Jak było wspomniane w komentarzu przez szanowanego malefixa,
    "— Licencje mogą być powiązane z liczbą użytkowników — wtedy naruszacie licencję.
    — Oprogramowanie może działać niepoprawnie przy kilku uruchomionych instancjach — wystarczy, że w jednym miejscu zapisuje śmieci lub ustawienia nie w profilu użytkownika/%temp%, a w coś publicznego — potem będzie Wam bardzo wesoło łapać problem"
  5. Przemyślamy, gdzie zostanie zainstalowany serwer graficzny, nie zapominając o UPS oraz dostępności tam portów ethernetowych o dużej prędkości i internetu (jeśli jest to konieczne), a także zgodności z wymaganiami klimatycznymi serwera.
  6. Czas wdrożenia zwiększamy co najmniej do 2,5-3 tygodni, ponieważ wiele nawet drobnych niezbędnych komponentów może podróżować do dwóch tygodni, a montaż i konfiguracja zajmuje kilka dni — sama zwykła inicjalizacja serwera do systemu operacyjnego może trwać ponad 5 minut.
  7. Omówmy z kierownictwem i dostawcami, że jeśli przypadkiem na którymkolwiek etapie projekt nie pójdzie lub pójdzie nie tak, to można zrealizować zwrot lub wymianę.
  8. Zostało miło zasugerowane w komentarzu malefixa,
    po wszystkich eksperymentach z ustawieniami — wszystko zniszczyć i zainstalować od nowa. Tak:
    — podczas eksperymentów należy dokumentować wszystkie krytyczne ustawienia
    Podczas instalacji od podstaw ponownie wykonujesz minimalne niezbędne ustawienia (które zostały udokumentowane na poprzednim etapie)
  9. System operacyjny (najlepiej Windows Server 2019 — z wysokiej jakości RDP) instalujemy na początku w trybie próbny, ale w żadnym wypadku nie w trybie evaluate (trzeba będzie później reinstalować od podstaw). Dopiero po udanym uruchomieniu rozwiązujemy kwestie licencjonowania i aktywujemy system operacyjny.
  10. Przed wdrożeniem także dobieramy grupę inicjatywną do testowania działania i wyjaśniamy przyszłym użytkownikom zalety korzystania z serwera graficznego. Jeśli robimy to później, zwiększamy ryzyko reklamacji, sabotażu oraz nieuzasadnionych negatywnych opinii.

Pod względem odczuć praca z RDP nie różni się od pracy w lokalnej sesji. Często wręcz zapomina się, że pracuje się gdzieś przez RDP — nawet wideo i czasami wideokonferencje w sesji RDP działają bez wyczuwalnych opóźnień, ponieważ większość osób korzysta dzisiaj z szybkiego internetu. Z szybkości i funkcjonalności RDP firma Microsoft nadal pozytywnie zaskakuje, a sprzętowe przyspieszenie 3D oraz wielomonitorowość to wszystko, co konieczne dla użytkowników programów graficznych, 3D i CAD/CAM do pracy zdalnej!

Tak więc w wielu przypadkach instalacja serwera graficznego zgodnie z przeprowadzonym wdrożeniem jest bardziej preferowana i mobilna niż 10 stacji graficznych lub komputerów.

P.S. Jak łatwo i bezpiecznie połączyć się przez internet przez RDP, a także optymalne ustawienia dla klientów RDP — można podejrzeć w artykule "Zdalna praca w biurze. RDP, Port Knocking, Mikrotik: prosto i bezpiecznie"

Źródło: habr.com

Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS 🔥 Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS | ProHoster