A vészhelyzeti hozzáférés bekapcsolása
A vészhelyzeti hozzáférés (OLCRTC) beállítása a felhasználói számára: Pro-előfizetés, vészhelyzeti útvonal, a fürt kapcsolója és a kiszolgálónkénti runtime — lépésről lépésre, a helyes sorrendben.
Ez az oldal Önnek, a szolgáltatás tulajdonosának szól. Arról szól, hogyan kapcsolja be a vészhelyzeti hozzáférést, hogy a felhasználói számíthassanak rá. Maguknak a felhasználóknak külön oldalak szolgálnak: Vészhelyzeti hozzáférés — hogyan működik, és mit kell tenni blokkolás idején — és A vészhelyzeti alkalmazás telepítése — honnan tölthető le az alkalmazás, és hogyan telepíthető.
A vészhelyzeti hozzáférés (OLCRTC) tartalék csatorna az engedélyezési listát használó hálózatokhoz, ahol a szokásos kapcsolat egyáltalán nem jut át. A forgalom továbbra is az Ön saját kiszolgálóin megy keresztül, de egy engedélyezett szolgáltatásban zajló videohívásnak álcázzuk. Ez nem második protokoll, és nem a fő protokoll helyettesítője: lassabb, rövid munkamenetekre való, a felhasználó kézzel indítja, és csak akkor, amikor minden más már nem működik.
A funkció kísérleti, és szakaszosan vezetjük be. Még ha minden kapcsoló be is van kapcsolva, a vészhelyzeti runtime még nem biztos, hogy telepítve van a kiszolgálóira, és a munkamenetek indítása sem feltétlenül aktív: a hozzáférés fokozatosan nyílik meg. Ha egy kiszolgáló a bekapcsolás után sokáig nem kerül „egészséges” állapotba, nagy valószínűséggel a bevezetés egyszerűen még nem ért el Önhöz.
Emellett nem működik minden hálózaton és minden országban, és függ egy külső videószolgáltatás és az e-mail elérhetőségétől. Ne ígérje garantált képességként — helyesebb a kemény blokkolások esetére szóló biztosításként bemutatni.
Mi szükséges hozzá
- Pro-előfizetés (vagy Max, amely mindent tartalmaz a Próból);
- legalább egy vészhelyzetinek jelölt útvonal;
- bekapcsolt OLCRTC-kapcsoló a fürtön;
- a fürt legalább egy kiszolgálója bekapcsolt runtime-mal;
- megerősített e-mail-címmel és aktív fiókkal rendelkező felhasználók (részletesen a korlátozásokról szóló szakaszban alább).
A bekapcsolás sorrendje
Három kapcsoló van, három különböző helyen, és könnyű összekeverni őket — kettő közülük szinte azonos nevű:
| Mit kapcsol be | Hol található | Mi a neve |
|---|---|---|
| Útvonal | útvonalbeállítások (szerkesztéskor) | „Vészhelyzeti útvonal (OLCRTC)” |
| Fürt | a fürt oldala, az útvonallista fölött | „OLCRTC bekapcsolása ehhez a fürthöz” |
| Kiszolgáló | kiszolgálópanel, „Szerkesztés” gomb | „OLCRTC futtatása ezen a kiszolgálón” |
A sorrend számít: a fürt nem engedi bekapcsolni az OLCRTC-t, amíg nincs egyetlen vészhelyzeti útvonal sem. Előbb az útvonal, aztán a fürt.
Fizessen elő a Prora. Nyissa meg a Fizetés részt → előfizetési blokk. Aktív Pro nélkül a vészhelyzeti hozzáférés kapcsolói meg sem jelennek: a fürt oldalán helyettük a „Vészhelyzeti hozzáférés (OLCRTC)” kártya látszik, „Előfizetés” gombbal.
Jelöljön meg egy útvonalat vészhelyzetiként — magának az útvonalnak a beállításaiban. Nyissa meg az útvonalat szerkesztésre, és a „Vészhelyzeti hozzáférés (OLCRTC)” blokkban kapcsolja be a „Vészhelyzeti útvonal (OLCRTC)” kapcsolót.
A kapcsoló csak meglévő útvonal szerkesztésekor jelenik meg. Az új útvonal létrehozására szolgáló űrlapon nincs meg: előbb hozza létre az útvonalat, azután nyissa meg a beállításait, és jelölje meg vészhelyzetiként.
Az adott útvonal kiszolgálói bekerülnek a vészhelyzeti készletbe. Több útvonalat is megjelölhet — a készlet mindet egyesíti, és ha az egyik útvonalon nincs alkalmas kiszolgáló, a kapcsolat egy másik útvonal kiszolgálójára kerül. A megjelölt útvonalak az útvonallistában vészhelyzeti címkét kapnak.
Kapcsolja be az OLCRTC-t az egész fürtre. Ez egy második, külön kapcsoló — nem az, amelyik az útvonalban van. A fürt oldalán található, az OLCRTC-címkével ellátott „Vészhelyzeti hozzáférés” blokkban, közvetlenül az útvonallista fölött, és a neve „OLCRTC bekapcsolása ehhez a fürthöz”.
Ez a főkapcsoló: amíg ki van kapcsolva, a fürt felhasználói semmit sem tudnak igényelni, bárhány útvonalat jelölt is meg vészhelyzetiként. A kapcsoló alatt látszik, hány vészhelyzeti útvonal van már a készletben.
Engedélyezze az indítást a kiszolgálókon. Kattintson egy kiszolgálóra, hogy megnyíljon a panelje, keresse meg a Vészhelyzeti runtime (OLCRTC) blokkot, nyomja meg a „Szerkesztés” gombot, kapcsolja be az „OLCRTC futtatása ezen a kiszolgálón” beállítást, és nyomja meg a „Mentés” gombot.
A runtime a háttérben magától települ és frissül — nem kell belépnie a kiszolgálóra. Amíg nem települt és nem jelentkezett be, az állapot „nem egészséges” lesz; ez normális, várja meg az „egészséges · N/M aktív” állapotot.
A blokk csak a szokásos felületmódban látható — az egyszerűsített Single módban nincs meg.
Adja meg a kapacitást. Ugyanabban a blokkban — Max. egyidejű munkamenet. A mezőt üresen is hagyhatja, de jobb, ha nem: lásd a következő szakaszt.
Tájékoztassa a felhasználóit. A vészhelyzeti hozzáférés haszontalan, ha akkor értesülnek róla, amikor már blokkolás alatt vannak: az alkalmazást előre kell telepíteni. Irányítsa őket a Vészhelyzeti hozzáférés és Az alkalmazás telepítése oldalra, és kérje meg őket, hogy egyszer járják végig a teljes folyamatot, amíg az internet még rendesen működik.
Hány munkamenetet bír el egy kiszolgáló
Egy vészhelyzeti munkamenet nem „még egy VPN-felhasználó” — érezhetően drágább: a kiszolgáló videofolyamba csomagolja a forgalmat, és ez processzoridőbe kerül.
Élő munkameneten végzett mérés szerint (Full HD videó nézése, körülbelül 5 Mbit/s) egy munkamenet nagyjából egy mag 15%-át és 31 MB memóriát foglal. A memória szinte semmit sem számít; a valódi korlát a processzor.
| Magok a kiszolgálón | Ésszerű kapacitás |
|---|---|
| 1 | 3 |
| 2 | 6–7 |
| 4 | 12–14 |
Ezek fölé még dedikált kiszolgálón se menjen: már négy munkamenet egyetlen magon annak nagyjából 60%-át jelenti, plusz a háttérterhelést. És vegye figyelembe, hogy a mérés videónézés közben készült (~5 Mbit/s); ha egy felhasználó kihajtja az alagutat, egy munkamenet érezhetően többe kerülhet.
Az üres kapacitásmező azt jelenti: „nincs korlát”. Ekkor az egyetlen védelem az az automatika, amely leáll az új munkamenetek kihelyezésével egy súlyosan túlterhelt kiszolgálóra. Ez azonban késleltetéssel reagál, és egy gyenge kiszolgálón addigra már a szokásos felhasználói is szenvedni fognak. Egymagos kiszolgálókon kifejezetten adja meg a kapacitást.
A terheléselosztás részben segít: ha az útvonalnál a terhelés szerinti algoritmus van kiválasztva (ez az alapértelmezett), a magas processzorterhelésű kiszolgáló kevesebb szabad sávszélességet jelent, és az új szokásos felhasználókat a rendszer kevésbé terhelt kiszolgálókra irányítja. De ez az általános processzorterhelés szerinti korrekció, nem a vészhelyzeti munkamenetek számlálása, és több perc késéssel működik — nem helyettesíti a kifejezetten megadott kapacitást.
Mi látszik a felületen
Minden kiszolgáló Vészhelyzeti runtime (OLCRTC) blokkjában:
- Lehetőség — futhatnak-e munkamenetek ezen a kiszolgálón;
- Kapacitás — az Ön korlátja az egyidejű munkamenetekre („nincs megadva” = nincs korlát);
- Runtime — állapot: „egészséges · N/M aktív”, „nem egészséges” vagy „még nem jelent”.
Közvetlenül a bekapcsolás után számítson a „nem egészséges” állapotra — ez normális, a kiszolgáló még telepíti a runtime-ot, és még nem jelentkezett be. Ha az állapot sokáig fennmarad, ellenőrizze, hogy a kiszolgáló egyáltalán elérhető-e. A „még nem jelent” felirat csak az oldal betöltése közben villan fel.
Korlátok, amelyeket érdemes előre ismerni
Egy munkamenet legfeljebb 12 óráig él, azután magától leáll. Nem hosszabbítható meg — a felhasználó új hívást hoz létre, és új levelet küld.
Felhasználónként egy munkamenet. A második levél nem hoz létre semmit, és válasz nélkül marad — érdemes ezt előre elmagyarázni a felhasználóknak, hogy ne tűnjön hibának.
Körülbelül 14 Mbit/s letöltés és egy megabitnél kevesebb feltöltés, 175–235 ms késleltetéssel. Videót nézni és levelezni kényelmes; nagy fájlokat küldeni, videohívást indítani és játszani nem. Ez a jelenlegi alagútkonfiguráció felső határa, nem a fő kapcsolaté.
A felhasználókkal szemben támasztott követelmények szigorúbbak, mint amilyennek látszanak. Megerősített e-mail-cím szükséges — akiket kézzel, e-mail nélkül vitt fel, azok nem tudnak hozzáférést igényelni. A fióknak ezenfelül aktívnak kell lennie: a felfüggesztett, lejárt, a keretüket kimerített és az első fizetésre váró fiókok (on_hold — mindenki, aki maga regisztrált, és még nem fizetett) elutasításra kerülnek. A levélnek át kell mennie a feladóhitelesítésen, a gyakoriság pedig korlátozott: felhasználónként öt kérés óránként, az egész szolgáltatásra pedig száz.
Az ezeken az ellenőrzéseken való elutasítás némán történik: a felhasználó semmilyen választ nem kap. Ha valaki azzal fordul Önhöz, hogy „elküldtem a levelet, és semmi sem jött”, kezdje a fiók állapotával, és azzal, hogy a megfelelő híváshivatkozást küldte-e el.
A többugrásos útvonalak nem vesznek részt. A vészhelyzeti munkamenetekhez csak közvetlen útvonalakat használunk.
Az iPhone bonyolultabb. Az iOS-kliens csak sideloaddal telepíthető, az Apple-nél nincs meg. Az iPhone-t használó felhasználóinak előre és körültekintőbben kell felkészülniük; ezt a telepítési útmutató írja le.
Hogyan kapcsolható ki
Az OLCRTC bekapcsolása ehhez a fürthöz jelölést bármikor eltávolíthatja — új munkamenetek nem indulnak többé. A már elindultak kitöltik a saját idejüket.
Az utolsó vészhelyzeti útvonalról bekapcsolt OLCRTC mellett nem vehető le a jelölés, és az útvonal sem törölhető: előbb jelöljön meg egy másik útvonalat, vagy kapcsolja ki az OLCRTC-t a fürtön.
Ha a Pro-előfizetés lejárt, kikapcsolni mindent lehet, visszakapcsolni viszont csak a megújítása után.