Piszki Lab

Analiza przypadku w języku przodków…

Przypadkowe rozpinanie się sesji PCoIP – diagnostyka i optymalizacja.

| 0 comments

W naszym laboratorium mamy całkiem niezłe środowisko, wyłączając niestety sieć. Jakoś tak się złożyło, że siecią administruje kto inny i do labu trafiają śmieci. Stare routery, jeszcze starsze switche etc. etc. W momencie w którym cały nasz dział przeszedł na cienkie terminale, zaczęliśmy odczuwać dzikie fluktuacje które ostatecznie sprowadziły się do nagminnego, zupełnie przypadkowego, rozpinania się sesji PCoIP. Diagnostyka problemu jest bardzo trudna, często zdarzało się tak, że jeden terminal działał sobie godzinami bez problemu, a gniazdko obok, nie dało się pracować, co minuta restart sesji. W logach sesji często pojawiał się komunikat: No PCoIP data received in the past 3 seconds (connection to peer might be lost). I to w trakcie intensywnej pracy a wirtualnej maszynie!

W tym miejscu bardzo bym chciał pochwalić autora programu PVoIP Log Viewer, genialne narzędzie, dosłownie wywleka na światło dzienne wszystkie parametry naszej sesji PCoIP.

pcoip1

Dzięki wykresowi z opóźnieniami, bardzo łatwo możemy stwierdzić, jak duże problemy mamy w sieci.

pcoip2

W naszym przypadku, oprócz uruchomienia projektu przebudowy sieci w labie (PCoIP Network Design Checklist), pomogło uelastycznienie sesji PCoIP. Przede wszystkim rozszerzony został zakres dynamicznego określania jakości przesyłanych ramek obrazu do wartości od 30 do 100% (czyli cały dopuszczalny zakres). Dodatkowo został włączony parametr Disable Build To Lossless (dopuszczamy możliwość przesłania obrazu o gorszej jakości niż wzorcowa (powstała na maszynie)). I najważniejszy parametr, czyli Session Lost Timeout:

pcoip3

To jest dokładnie ta wartość, która określa moment, po jakim terminal uznaje, że nastąpiło zerwanie połączenia sieciowego. Nawet jeśli okaże się, że użytkownik doświadczy chwilowego “zamrożenia” sesji, to jeśli nie przekroczymy 10 sekund, sesja zostanie wznowiona bez wylogowania użytkownika (wylogowania terminala a nie sesji na wirtualnej maszynie). Opisane przeze mnie ustawienia zwiększyły komfort pracy użytkowników, nie zapobiegły jednak przypadkowym rozpięciom. Wyszperałem nawet taką informację, i faktycznie, u mnie w logu też pojawiały się stosowne komunikaty(MGMT_CMI :Failed multiple attempts to contact SOAP server!):

pcoip4

Niestety, nadanie stałego adresu IP nie rozwiązało problemu. Ale za to naprowadziło mnie na rozwiązanie (jak zawsze, najciemniej jest pod latarnią), w momencie w którym terminal “wstał” ze stałym adresem IP… praktycznie natychmiast się zrestartował i wstał z adresem z DHCP! Po konsultacjach z dokumentacją, okazało się, że winna restartów terminali jest opcja włączająca trwałą konfigurację. Nowa partia terminali jaka do nas dotarła, miała ustawione hasło domyślne, aby inicjalna sekwencja zadziałała (włączenie –> dhcp –> profil), do ustawień automatycznej konfiguracji dodaliśmy to hasło i … siłą rozpędu hasło które było wpisane w profilu! Tak więc zgodnie z ostrzeżeniem z punktu 4.3.4 dokumentacji (Persistent AutoConfig: WARNING: ENABLING THIS FEATURE MAY RESULT IN DEVICES BEIGN RESET WHILE USERS ARE IN SESSION), takie ustawienie stosownych opcji (wraz z hasłami), to BARDZO ZŁE ustawienie:

pcoip5

Należy wyłączyć DHCP Option Matching i Persistent AutoConfig, zamiast tego profile można rozsyłać zgodnie z harmonogramem np. po pracy użytkowników. A problemów będzie zdecydowanie mniej Uśmiech

Oceń ten artykuł:
[Głosów:0    Średnia:0/5]

Dodaj komentarz

Required fields are marked *.


.

Podobał się wpis? Wesprzyj Piszki Lab, kliknij w reklamę! :-)

.