Monitorimi i licencës së softuerit. Instalimi i veçantë i bibliotekës për botimet e mëparshme
- tutorial
Shumë kompani përdorin 1C si platformën kryesore të automatizimit. Kështu ndodhi me ne. Megjithatë, procesi i krijimit të platformës u krye pa një qasje të duhur, në lidhje me të cilën fillimisht kishim 5 çelësa mbrojtës për 95 licenca, më pas u shfaqën 3 çelësa të tjerë fizikë për të siguruar 50 licenca të tjera klienti për 3 persona juridikë. Situata është marrëzi, pasi çdo çelës normalisht kërkon hoste të veçantë, dhe kishte gjithnjë e më pak serverë të përshtatshëm për këtë, dhe rritja e mundshme e numrit të përdoruesve dhe, rrjedhimisht, blerja e çelësave të rinj, më bëri të mendoj për një zgjidhje alternative. për të shmangur ngarkesën e panevojshme të informacionit në serverët tanë dhe në përgjithësi për ta bërë sistemin kyç më fleksibël dhe, mundësisht, më të qëndrueshëm.
Zgjedhja e sistemit
Sistemi i virtualizimit
Si sistem vizualizimi u zgjodh Esxi 5.1. Zgjedhur për mbështetje të mirë për transferimin e pajisjes USB dhe sepse, përveç ESX, kuptoj vetëm Hyper-V, i cili nuk mbështet transferimin e pajisjes.Për të transferuar pajisjet USB në ESX, hardueri i sistemit të ftuar duhet të jetë së paku versioni 7. Më pas do të jetë e mundur të shtoni një kontrollues USB dhe të hartoni pajisjen USB në sistemin e ftuar. Ekziston edhe një pikë për mbështetjen. Zyrtarisht, VMware mbështet vetëm një listë të caktuar të pajisjeve. Dhe ai nuk është shumë i madh. Megjithatë, çelësat e zakonshëm të sigurisë të Aladdin duket se mbështeten. Lista e pajisjeve të mbështetura është në faqen zyrtare të internetit. Dhe një përshkrim i kërkesave dhe dispozitave për bllokimin e USB-së në sistemin e mysafirëve është gjithashtu në faqen zyrtare të internetit, në bazën e njohurive.
Ka mënyra alternative për të transferuar çelësat USB në një mjedis virtual dhe në atë fizik gjithashtu. Këto pajisje dhe softuer janë të ashtuquajturat USB mbi IP. Në këtë rast, produktet softuerike nuk janë shumë interesante për t'u marrë në konsideratë, por produktet e hekurit në këtë rast shfaqen mirë. Përfaqësuesi më i ndritshëm, AnywhereUSB i mirënjohur me 14 porte. Është i instaluar në një raft, ka dy ndërfaqe dhe dy hyrje të energjisë (nëse ka vërtet dy furnizime me energji, nuk e di :)). Pajisja është e mirë për të gjithë, por kushton mesatarisht 60 mijë rubla, të cilat nuk përshtateshin mirë në buxhetin tonë.
Kështu, pas testeve dhe provave, u zgjodh platforma e virtualizimit dhe u braktis përdorimi i produkteve të tjera.
Sistemi operativ dhe drejtuesit HASP
Zgjodha Debian si OS. Pse? Vetem sepse. Në fakt, në këtë konfigurim, mund të merrni çdo komplet të preferuar të shpërndarjes. Por më pëlqen gjithmonë Debian për stabilitetin dhe depon e tij të mirë.
Një paketë mjaft e njohur nga Etersoft merret si drejtues. Ju mund ta merrni paketën e përpiluar për shpërndarjen tuaj në serverin FTP të kompanisë: ftp.etersoft.ru/pub/Etersoft/HASP/stable .
Pas instalimit të paketës, shfaqet shërbimi haspd, i cili kontrollon funksionimin e dongle.
Konfigurimi dhe verifikimi
Nuk kërkon ndonjë konfigurim shtesë. Çelësi fillon të punojë pothuajse jashtë kutisë.Ne kontrollojmë. Programi haspdemo është përfshirë për të kontrolluar funksionalitetin. Pas identifikimit të suksesshëm të çelësit dhe fillimit të punës, programi do të nxjerrë diçka të tillë në tastierë:
LOCALHASP_ISHASP: Rezultati: 1
Përdorimi i fjalëkalimeve 15213 - 28875
LOCALHASP_HASPSTATUS: Numri i versionit të API është 8.0
numri i portit 201
Lloji i çelësit: HASP4 M4
LOCALHASP_HASPGENERATION: OK, HASP4 është i lidhur.
LOCALHASP_HASPNETSTATUS: çelësi i lidhur është HASP4 Net 20
MEMOHASP_HASPID: 436444258 (decimal), 0x1a039c62 (heks)LOCALHASP_ENCODETATA: OK.
53 C1 F1AF | EC 16 C3 15 | 35 31 E4 7F | 9B D0 90 9F
AA BA 8C 80 | 1E 22 29 E2 | 92 7E 04 56 | DA 70 7B 63 [.....")..~.V.p(c]
23 B4 9B E6 | 2F 17 | | [#.../.]NETHASP_READBLOCK: Dështoi: Statusi i kthimit: 10
Fusha kryesore: LOCALHASP_ISHASP: Rezultati: 1 . Duke ju thënë se gjithçka është në rregull. Më tej shkruhet se cili çelës është futur.
Megjithatë, nëse ka ndonjë problem, atëherë mesazhi shfaqet më i shkurtër:
Ky është një program i thjeshtë demo për çelësin HASP4
E drejta e autorit Aladdin Knowledge Systems Ltd.LOCALHASP_ISHASP: Dështoi: statusi = -100
Për më tepër, në fakt, nuk ka rëndësi se çfarë ndodh me çelësin, ai mund të mos futet, shërbimi mund të mos funksionojë ose diçka tjetër. Unë kam parë vetëm dy vlera LOCALHASP_ISHASP deri më tani. Është ose: Rezultati: 1 ose: Dështoi: statusi = -100 . Dhe kjo e fundit gjithmonë korrespondonte me mosfunksionimin, dhe e para gjithmonë nënkuptonte që gjithçka ishte në rregull. Nuk gjeta dokumentacion për këtë paketë, ndaj nuk munda të zbuloja se çfarë statusesh të tjera ka.
Mbaroi me çelësin. Nuk duhet të harrojmë se çelësi juaj i sapokrijuar do të shfaqet në monitorin e çelësave vetëm kur të merret të paktën një licencë prej tij. Më pas monitori aladdin do të tregojë informacionin që tregon zakonisht: ky është lloji i çelësit, numri i licencave të marra, licencat totale, kush e ka marrë saktësisht licencën dhe afatin.
Është mjaft e thjeshtë ta detyrosh këtë, mjafton të specifikosh manualisht një menaxher të ri licence në klientin nethasp.ini. Por për vendosjen e klientit pak më vonë.
Nga ky moment, detyra fillestare mund të konsiderohet e përfunduar. Tani mund të krijojmë disa makina virtuale paralelisht, në një sasi që korrespondon me numrin e çelësave fizikë të disponueshëm. Burimet e tilla virtualka konsumojnë, natyrisht, qindarkë.
Problemet dhe Zgjidhjet
Pika e vetme e dështimit
Problemi i parë që krijohet dhe në pamje të qartë është krijimi i një pike dështimi. Nëse më parë çelësat shpërndaheshin në serverë të ndryshëm dhe dështimi i më shumë se një çelësi praktikisht përjashtohet, atëherë në këtë rast dështimi i serverit fizik mund të çojë në dështimin e të gjithë sistemit 1C, sepse. klientët do të bien brenda, për mendimin tim, brenda 600 sekondave dhe pas një kohe të shkurtër të gjithë do të bien dhe nuk do të mund të kthehen në sistem. Nuk mund të thuhet se çfarë do të pasojë një incident i tillë. Ka dy zgjidhje dhe ato drejtohen në drejtime të ndryshme. Zgjidhja e parë është përdorimi i një konfigurimi ESX të dështimit. Sidoqoftë, kjo ka kuptim nëse kompania juaj e ka vendosur tashmë këtë sistem dhe ka përmbushur tashmë një numër kërkesash për të ruajtur funksionimin në rast të dështimit të ndonjë komponenti. Një zgjidhje tjetër është më e parëndësishme:Ne krijojmë një grup regjistrimesh A në DNS të kompanisë sonë. Për shembull, çelësi1, çelësi2, çelësi3 dhe kështu me radhë. Ne futim emrat DNS në klientët nethasp.ini, shpërndajmë skedarin duke përdorur politikën e grupit. Kështu, marrim një strukturë aksesi mjaft fleksibël. Në këtë rast, pasi të zbuloni një problem të rëndësishëm me serverin virtual esx, mund t'i zhvendosni shpejt çelësat në çdo server tjetër, përfshirë. në stacionet e punës të çdo punonjësi. Paralelisht, ne zëvendësojmë rekordet A me të reja. Për ca kohë, cache-i i klientëve do të mbarojë dhe ata përsëri do të jenë në gjendje të marrin një licencë të re dhe të vazhdojnë të punojnë.
Unë rekomandoj të vendosni rekorde të kundërta DNS për çelësat, përndryshe monitori aladdin nuk do të tregojë emrin e hostit, por do të tregojë vetëm ID-në e menaxherit të licencës, gjë që nuk është shumë e përshtatshme.
Nëse kompania juaj dhe gjithçka përdor një metodë të shpërndarjes së çelësit të transmetimit, atëherë gjithçka thjeshtohet dhe zhvendosja e çelësit në një host tjetër brenda domenit të transmetimit nuk do të ndikojë në asnjë mënyrë në punën tuaj.
Bien çelësat
Ekziston një problem mjaft i zakonshëm. Bien çelësat. Megjithatë, asnjë lidhje e veçantë nuk u vërejt. Kjo ndodh në kontrollues të ndryshëm, madje edhe në sisteme të ndryshme pritës. Kur i zhvendosa çelësat dhe i vendosa përkohësisht në një vend tjetër nën kontrollin e VMware Player, çelësat binin shpesh. Kjo shprehet në mënyrë të parëndësishme. Kur kërkoni haspdemo, shfaqet rreshti LOCALHASP_ISHASP: Dështoi: status = -100. Edhe pse çelësi është futur dhe zbuluar. dmseg tregon linja që nuk kuptohen plotësisht: usb 2-2.1: usbfs: USBDEVFS_CONTROL dështoi cmd aksusbd rqt 192 rq 139 len 8 ret -110Problemi zgjidhet aq i parëndësishëm sa duket - duke rifilluar shërbimin. Por sedimenti mbetet dhe derisa të bëhet kjo, serveri nuk do të shpërndajë çelësat. Meqenëse unë dua që sistemi të funksionojë pa të meta, u vendos të shkruaj një skenar që do të rivendoste vetë menaxherin e licencës. Pra, me ndihmën e një miku, u shkrua një skript që ekzekuton haspdemo dhe përpiqet të kuptojë nëse statusi po kthehet normal apo jo:
[ "`haspdemo | sed -n "s/^LOCALHASP_ISHASP.* \(\-\?*\)$/\1/p"`" == "-100" ] && shërbimi haspd rinis
Më tej, ky skenar futet në lëshimin e CRON çdo minutë dhe kaq. Edhe nëse sistemi juaj nuk e ka problemin e rënies së porteve, ky skenar, mendoj se nuk do të dëmtojë.
Problemi i zbulimit të çelësit të klientit
Dhe ekziston një problem i tillë. Ai konsiston në faktin se klienti, pas humbjes së çelësit, mund të mos dëshirojë të marrë një çelës të ri. Gjithashtu, ky problem mund të shprehet në manifestime të tjera. Për shembull, nëse keni ndryshuar shtigjet për çelësat në skedarin nethasp.ini, atëherë aplikacioni i klientit mund të vazhdojë me shumë gëzim të raportojë se nuk ka çelësa dhe nuk i ka parë kurrë. Nëse nuk jeni gati për një reagim të tillë, atëherë problemi bëhet shumë i pakëndshëm dhe filloni të kontrolloni furishëm funksionimin e të gjithë sistemit dhe të shani pseudonimet 1C, sepse gjithçka funksionon, por GlavBukh ose, siç do ta kishte fat, Gjenerali, tani nuk mund të hyni në 1Sku për ndonjë arsye të panjohur dhe ju ndiheni si një idiot në vend që ta rregulloni problemin shpejt. Sidoqoftë, një zgjidhje mjaft e thjeshtë ka ndihmuar deri më tani. Është e nevojshme të pastroni cache 1C nga profili i përdoruesit. Në një kohë, gjeta një skedar të veçantë që është përgjegjës për këtë informacion, harrova se cilin :(Çelësat thjesht mund të ndalojnë së punuari
Askush nuk është i imunizuar nga dështimi i pajisjeve. Dhe këta çelësa patetikë mund të ndalojnë së punuari gjithashtu. Dhe gjëja më e rëndësishme në këtë rast është ta zbuloni sa më shpejt që të jetë e mundur. Për ta bërë këtë, ne do të përdorim sistemin e monitorimit Zabbix. Sigurisht, vendosja e tij vetëm për monitorimin e çelësave është e kotë, por nëse Zabbix është instaluar tashmë, atëherë pse të mos bashkëngjitni monitorimin e gjendjes së çelësave në të.Për ta bërë këtë, ne duhet të shkruajmë skriptin tonë në skedarin e cilësimeve të agjentit. Ne po kërkojmë skedarin e konfigurimit të zabbix_agent të instaluar, ai quhet zabbix_agentd.conf. Hapeni dhe shtoni rreshtin
UserParameter=hasp.status,haspdemo | grep "^LOCALHASP_ISHASP" | sed "s/^.* \(\-\?*\)$/\1/g"
Kjo do të lejojë komandën të mbledhë një vlerë numerike në fushën LOCALHASP_ISHASP. Në vetë zabbix, gjithçka është shtuar tashmë në mënyrë primitive, ne krijojmë artikull për hostin ose shabllonin e dëshiruar, si lloji tregojnë agjenti zabbix, specifikoni si parametër kyç hasp.statusi. Lloji i vlerës - noton. Nëse dëshironi, ne krijojmë një shkas me të cilin do të merrni një letër ose SMS që çelësi nuk funksionon. Është më mirë ta konfiguroni këtë shkas në atë mënyrë që të kërkojë të paktën 2 goditje dhe të mbulojë kohën e kërkuar nga skripti i rikuperimit automatik i përshkruar më sipër, përndryshe do të shfaqen mesazhe të rreme për problemet me çelësin.
Me cilësimet e sakta, vetëm nëse çelësi nuk funksionon plotësisht, do të merrni një njoftim për problemet.
Bonus
Doli të ishte një surprizë për mua, por shumë njerëz me të vërtetë nuk e dinë se është e mundur të detyrohen pjesët e klientit 1C të kërkojnë çelësa në adresat IP të specifikuara duke përdorur një lidhje TCP ose UDP. Në të vërtetë, shumë njerëz vendosin infrastrukturën e tyre në mënyrë që çdo domen transmetimi të ketë një numër të mjaftueshëm çelësash. Kjo është egërsi. Për ata që nuk e dinë ende, këtu është një udhëzues i shpejtë:Për të kontrolluar aksesin në çelësin hasp, ekziston një skedar nethasp.ini në klient. Ndodhet në dosjen \conf të drejtorisë 1C. Ne jemi të interesuar për seksionin Në këtë seksion, ne duhet të çkomentojmë ose të krijojmë opsionet e mëposhtme:
- NH_SERVER_ADDR. Këtu ne specifikojmë një listë të emrave DNS ose adresave IP të serverëve me një menaxher licence të ndarë me presje.
- NH_USE_BROADCAST. Vendosni vlerën në Disabled.
- NH_TCPIP_METHOD. Metoda e parazgjedhur është UDP. Ju mund të ndryshoni në TCP, por në përgjithësi nuk ka nevojë serioze për këtë.
Një pikë tjetër në lidhje me shfaqjen e çelësave në monitorin aladdin. Në kundërshtim me besimin popullor, licencat falas nuk janë vetëm ato licenca që nuk përdoren në monitorin aladdin, por edhe ato që kanë 0 në fushën Timeout. Vlerat zakonisht zhduken brenda 36 orëve, por licencat ende konsiderohen të lira.
Në përfundim
Mendova për një kohë të gjatë nëse ka ndonjë pikë në një artikull të tillë, në fund të fundit, e gjithë kjo mund të gjendet në internet, megjithatë, duke pasur parasysh kohën që kalova vetë për të mbledhur të gjitha informacionet, mendova se do të ishte shumë mirë nëse të paktën dikush këtë Artikulli do të jetë i dobishëm dhe do të kursejë kohë.
Pyetje: Monitorimi i licencave të softuerit
Përgjigje:
Pyetje: Problem me licencat e softuerit në serverin 1c
Përgjigje:
Pyetje: Licenca e softuerit dhe lidhja COM
Është instaluar një licencë softueri.
Kur përpiqem të nis 1C përmes një lidhjeje Com, ai thotë:
-----------
Nuk u gjet asnjë licencë falas!
Gjetja e licencave te klienti:
Gabim në licencimin e softuerit
Është tejkaluar numri maksimal i përdoruesve të lejuar nga skedari i licencës së softuerit.
Burimi: V82.COMConnector.1
-----------
Cili është problemi?
Përgjigje:Është tejkaluar numri maksimal i përdoruesve të lejuar nga skedari i licencës së softuerit.
Pyetje: Si mund të zbuloj se cili skedar (.lic) korrespondon me cilën licencë softueri?
Përgjigje:
Pyetje: Truket e lëshimit të licencave të softuerit nga serveri 1C
Përgjigje:
Pyetje: Licencat e softuerit të klientit nuk shpërndahen
Përgjigje:
Pyetje: Problem me transferimin e një licence softueri 1C 8.3 në një server të ri
Mirembrema.
Kompania kishte një server fizik 1C 8.3 me bazat e të dhënave të skedarëve të kontabilitetit. Kishte licenca softuerike në të.
Licencat e blera për 1c ERP:
1.për platformë për 20 persona
2. te konfigurimi 3. te serveri 1 s Ne gjithashtu blemë një server të ri raft, instaluam platformën 1C 8.3 në të, vendosëm bazën e të dhënave të testit ERP, instaluam licencat e softuerit - gjithçka është në rregull.
Kishte një problem me transferimin e bazave të të dhënave të skedarëve, ose më saktë, unë kopjova vetë bazat e të dhënave, por kur nis 1C, nuk ofron të futësh një licencë, por thotë që licenca nuk u gjet dhe sugjeron përdorimin e një çelësi mbrojtjeje harduerike.
Më tregoni se si ta bëj 1C të sugjerojë prezantimin e një licence softueri për bazat e të dhënave të skedarëve të kontabilitetit në një server të ri?
Përgjigje: Super faleminderit!
Pyetje: v7: 1C 7.7 TiS - a mund të ketë një licencë softueri?
U përball me TiS 7.7 lokal pa një çelës sigurie harduerike. Me sa mbaj mend, TiS 7.7 nuk kishte dërgesa me licencë softueri? Mbaj mend që në 7-ke kishte disa produkte me aktivizim sipas fjalëve nga libri - duhej të gjeje një fjalë në filan faqe dhe pastaj u bë aktivizimi, domethënë pa çelës sigurie. Por duket se këto ishin disa vendime të industrisë, me sa mbaj mend. Ka një kuti me një pyetësor, disqe dhe libra, por nuk ka asnjë çelës askund. Vërtetë, nuk ka asnjë port LPT në PC, kjo është ndoshta arsyeja pse ata nuk e instaluan atë në atë kohë dhe e humbën atë diku. Por prapëseprapë, do të doja të sigurohesha që nuk kishte TIS me aktivizimin e softuerit, vetëm me harduer? Papritur, thjesht kam hasur gjithmonë pajisje më parë.
Përgjigje:
Përgjigje:
- tutorial
Shumë kompani përdorin 1C si platformën kryesore të automatizimit. Kështu ndodhi me ne. Megjithatë, procesi i krijimit të platformës u krye pa një qasje të duhur, në lidhje me të cilën fillimisht kishim 5 çelësa mbrojtës për 95 licenca, më pas u shfaqën 3 çelësa të tjerë fizikë për të siguruar 50 licenca të tjera klienti për 3 persona juridikë. Situata është marrëzi, pasi çdo çelës normalisht kërkon hoste të veçantë, dhe kishte gjithnjë e më pak serverë të përshtatshëm për këtë, dhe rritja e mundshme e numrit të përdoruesve dhe, rrjedhimisht, blerja e çelësave të rinj, më bëri të mendoj për një zgjidhje alternative. për të shmangur ngarkesën e panevojshme të informacionit në serverët tanë dhe në përgjithësi për ta bërë sistemin kyç më fleksibël dhe, mundësisht, më të qëndrueshëm.
Zgjedhja e sistemit
Sistemi i virtualizimit
Si sistem vizualizimi u zgjodh Esxi 5.1. Zgjedhur për mbështetje të mirë për transferimin e pajisjes USB dhe sepse, përveç ESX, kuptoj vetëm Hyper-V, i cili nuk mbështet transferimin e pajisjes.Për të transferuar pajisjet USB në ESX, hardueri i sistemit të ftuar duhet të jetë së paku versioni 7. Më pas do të jetë e mundur të shtoni një kontrollues USB dhe të hartoni pajisjen USB në sistemin e ftuar. Ekziston edhe një pikë për mbështetjen. Zyrtarisht, VMware mbështet vetëm një listë të caktuar të pajisjeve. Dhe ai nuk është shumë i madh. Megjithatë, çelësat e zakonshëm të sigurisë të Aladdin duket se mbështeten. Lista e pajisjeve të mbështetura është në faqen zyrtare të internetit. Dhe një përshkrim i kërkesave dhe dispozitave për bllokimin e USB-së në sistemin e mysafirëve është gjithashtu në faqen zyrtare të internetit, në bazën e njohurive.
Ka mënyra alternative për të transferuar çelësat USB në një mjedis virtual dhe në atë fizik gjithashtu. Këto pajisje dhe softuer janë të ashtuquajturat USB mbi IP. Në këtë rast, produktet softuerike nuk janë shumë interesante për t'u marrë në konsideratë, por produktet e hekurit në këtë rast shfaqen mirë. Përfaqësuesi më i ndritshëm, AnywhereUSB i mirënjohur me 14 porte. Është i instaluar në një raft, ka dy ndërfaqe dhe dy hyrje të energjisë (nëse ka vërtet dy furnizime me energji, nuk e di :)). Pajisja është e mirë për të gjithë, por kushton mesatarisht 60 mijë rubla, të cilat nuk përshtateshin mirë në buxhetin tonë.
Kështu, pas testeve dhe provave, u zgjodh platforma e virtualizimit dhe u braktis përdorimi i produkteve të tjera.
Sistemi operativ dhe drejtuesit HASP
Zgjodha Debian si OS. Pse? Vetem sepse. Në fakt, në këtë konfigurim, mund të merrni çdo komplet të preferuar të shpërndarjes. Por më pëlqen gjithmonë Debian për stabilitetin dhe depon e tij të mirë.
Një paketë mjaft e njohur nga Etersoft merret si drejtues. Ju mund ta merrni paketën e përpiluar për shpërndarjen tuaj në serverin FTP të kompanisë: ftp.etersoft.ru/pub/Etersoft/HASP/stable .
Pas instalimit të paketës, shfaqet shërbimi haspd, i cili kontrollon funksionimin e dongle.
Konfigurimi dhe verifikimi
Nuk kërkon ndonjë konfigurim shtesë. Çelësi fillon të punojë pothuajse jashtë kutisë.Ne kontrollojmë. Programi haspdemo është përfshirë për të kontrolluar funksionalitetin. Pas identifikimit të suksesshëm të çelësit dhe fillimit të punës, programi do të nxjerrë diçka të tillë në tastierë:
LOCALHASP_ISHASP: Rezultati: 1
Përdorimi i fjalëkalimeve 15213 - 28875
LOCALHASP_HASPSTATUS: Numri i versionit të API është 8.0
numri i portit 201
Lloji i çelësit: HASP4 M4
LOCALHASP_HASPGENERATION: OK, HASP4 është i lidhur.
LOCALHASP_HASPNETSTATUS: çelësi i lidhur është HASP4 Net 20
MEMOHASP_HASPID: 436444258 (decimal), 0x1a039c62 (heks)LOCALHASP_ENCODETATA: OK.
53 C1 F1AF | EC 16 C3 15 | 35 31 E4 7F | 9B D0 90 9F
AA BA 8C 80 | 1E 22 29 E2 | 92 7E 04 56 | DA 70 7B 63 [.....")..~.V.p(c]
23 B4 9B E6 | 2F 17 | | [#.../.]NETHASP_READBLOCK: Dështoi: Statusi i kthimit: 10
Fusha kryesore: LOCALHASP_ISHASP: Rezultati: 1 . Duke ju thënë se gjithçka është në rregull. Më tej shkruhet se cili çelës është futur.
Megjithatë, nëse ka ndonjë problem, atëherë mesazhi shfaqet më i shkurtër:
Ky është një program i thjeshtë demo për çelësin HASP4
E drejta e autorit Aladdin Knowledge Systems Ltd.LOCALHASP_ISHASP: Dështoi: statusi = -100
Për më tepër, në fakt, nuk ka rëndësi se çfarë ndodh me çelësin, ai mund të mos futet, shërbimi mund të mos funksionojë ose diçka tjetër. Unë kam parë vetëm dy vlera LOCALHASP_ISHASP deri më tani. Është ose: Rezultati: 1 ose: Dështoi: statusi = -100 . Dhe kjo e fundit gjithmonë korrespondonte me mosfunksionimin, dhe e para gjithmonë nënkuptonte që gjithçka ishte në rregull. Nuk gjeta dokumentacion për këtë paketë, ndaj nuk munda të zbuloja se çfarë statusesh të tjera ka.
Mbaroi me çelësin. Nuk duhet të harrojmë se çelësi juaj i sapokrijuar do të shfaqet në monitorin e çelësave vetëm kur të merret të paktën një licencë prej tij. Më pas monitori aladdin do të tregojë informacionin që tregon zakonisht: ky është lloji i çelësit, numri i licencave të marra, licencat totale, kush e ka marrë saktësisht licencën dhe afatin.
Është mjaft e thjeshtë ta detyrosh këtë, mjafton të specifikosh manualisht një menaxher të ri licence në klientin nethasp.ini. Por për vendosjen e klientit pak më vonë.
Nga ky moment, detyra fillestare mund të konsiderohet e përfunduar. Tani mund të krijojmë disa makina virtuale paralelisht, në një sasi që korrespondon me numrin e çelësave fizikë të disponueshëm. Burimet e tilla virtualka konsumojnë, natyrisht, qindarkë.
Problemet dhe Zgjidhjet
Pika e vetme e dështimit
Problemi i parë që krijohet dhe në pamje të qartë është krijimi i një pike dështimi. Nëse më parë çelësat shpërndaheshin në serverë të ndryshëm dhe dështimi i më shumë se një çelësi praktikisht përjashtohet, atëherë në këtë rast dështimi i serverit fizik mund të çojë në dështimin e të gjithë sistemit 1C, sepse. klientët do të bien brenda, për mendimin tim, brenda 600 sekondave dhe pas një kohe të shkurtër të gjithë do të bien dhe nuk do të mund të kthehen në sistem. Nuk mund të thuhet se çfarë do të pasojë një incident i tillë. Ka dy zgjidhje dhe ato drejtohen në drejtime të ndryshme. Zgjidhja e parë është përdorimi i një konfigurimi ESX të dështimit. Sidoqoftë, kjo ka kuptim nëse kompania juaj e ka vendosur tashmë këtë sistem dhe ka përmbushur tashmë një numër kërkesash për të ruajtur funksionimin në rast të dështimit të ndonjë komponenti. Një zgjidhje tjetër është më e parëndësishme:Ne krijojmë një grup regjistrimesh A në DNS të kompanisë sonë. Për shembull, çelësi1, çelësi2, çelësi3 dhe kështu me radhë. Ne futim emrat DNS në klientët nethasp.ini, shpërndajmë skedarin duke përdorur politikën e grupit. Kështu, marrim një strukturë aksesi mjaft fleksibël. Në këtë rast, pasi të zbuloni një problem të rëndësishëm me serverin virtual esx, mund t'i zhvendosni shpejt çelësat në çdo server tjetër, përfshirë. në stacionet e punës të çdo punonjësi. Paralelisht, ne zëvendësojmë rekordet A me të reja. Për ca kohë, cache-i i klientëve do të mbarojë dhe ata përsëri do të jenë në gjendje të marrin një licencë të re dhe të vazhdojnë të punojnë.
Unë rekomandoj të vendosni rekorde të kundërta DNS për çelësat, përndryshe monitori aladdin nuk do të tregojë emrin e hostit, por do të tregojë vetëm ID-në e menaxherit të licencës, gjë që nuk është shumë e përshtatshme.
Nëse kompania juaj dhe gjithçka përdor një metodë të shpërndarjes së çelësit të transmetimit, atëherë gjithçka thjeshtohet dhe zhvendosja e çelësit në një host tjetër brenda domenit të transmetimit nuk do të ndikojë në asnjë mënyrë në punën tuaj.
Bien çelësat
Ekziston një problem mjaft i zakonshëm. Bien çelësat. Megjithatë, asnjë lidhje e veçantë nuk u vërejt. Kjo ndodh në kontrollues të ndryshëm, madje edhe në sisteme të ndryshme pritës. Kur i zhvendosa çelësat dhe i vendosa përkohësisht në një vend tjetër nën kontrollin e VMware Player, çelësat binin shpesh. Kjo shprehet në mënyrë të parëndësishme. Kur kërkoni haspdemo, shfaqet rreshti LOCALHASP_ISHASP: Dështoi: status = -100. Edhe pse çelësi është futur dhe zbuluar. dmseg tregon linja që nuk kuptohen plotësisht: usb 2-2.1: usbfs: USBDEVFS_CONTROL dështoi cmd aksusbd rqt 192 rq 139 len 8 ret -110Problemi zgjidhet aq i parëndësishëm sa duket - duke rifilluar shërbimin. Por sedimenti mbetet dhe derisa të bëhet kjo, serveri nuk do të shpërndajë çelësat. Meqenëse unë dua që sistemi të funksionojë pa të meta, u vendos të shkruaj një skenar që do të rivendoste vetë menaxherin e licencës. Pra, me ndihmën e një miku, u shkrua një skript që ekzekuton haspdemo dhe përpiqet të kuptojë nëse statusi po kthehet normal apo jo:
[ "`haspdemo | sed -n "s/^LOCALHASP_ISHASP.* \(\-\?*\)$/\1/p"`" == "-100" ] && shërbimi haspd rinis
Më tej, ky skenar futet në lëshimin e CRON çdo minutë dhe kaq. Edhe nëse sistemi juaj nuk e ka problemin e rënies së porteve, ky skenar, mendoj se nuk do të dëmtojë.
Problemi i zbulimit të çelësit të klientit
Dhe ekziston një problem i tillë. Ai konsiston në faktin se klienti, pas humbjes së çelësit, mund të mos dëshirojë të marrë një çelës të ri. Gjithashtu, ky problem mund të shprehet në manifestime të tjera. Për shembull, nëse keni ndryshuar shtigjet për çelësat në skedarin nethasp.ini, atëherë aplikacioni i klientit mund të vazhdojë me shumë gëzim të raportojë se nuk ka çelësa dhe nuk i ka parë kurrë. Nëse nuk jeni gati për një reagim të tillë, atëherë problemi bëhet shumë i pakëndshëm dhe filloni të kontrolloni furishëm funksionimin e të gjithë sistemit dhe të shani pseudonimet 1C, sepse gjithçka funksionon, por GlavBukh ose, siç do ta kishte fat, Gjenerali, tani nuk mund të hyni në 1Sku për ndonjë arsye të panjohur dhe ju ndiheni si një idiot në vend që ta rregulloni problemin shpejt. Sidoqoftë, një zgjidhje mjaft e thjeshtë ka ndihmuar deri më tani. Është e nevojshme të pastroni cache 1C nga profili i përdoruesit. Në një kohë, gjeta një skedar të veçantë që është përgjegjës për këtë informacion, harrova se cilin :(Çelësat thjesht mund të ndalojnë së punuari
Askush nuk është i imunizuar nga dështimi i pajisjeve. Dhe këta çelësa patetikë mund të ndalojnë së punuari gjithashtu. Dhe gjëja më e rëndësishme në këtë rast është ta zbuloni sa më shpejt që të jetë e mundur. Për ta bërë këtë, ne do të përdorim sistemin e monitorimit Zabbix. Sigurisht, vendosja e tij vetëm për monitorimin e çelësave është e kotë, por nëse Zabbix është instaluar tashmë, atëherë pse të mos bashkëngjitni monitorimin e gjendjes së çelësave në të.Për ta bërë këtë, ne duhet të shkruajmë skriptin tonë në skedarin e cilësimeve të agjentit. Ne po kërkojmë skedarin e konfigurimit të zabbix_agent të instaluar, ai quhet zabbix_agentd.conf. Hapeni dhe shtoni rreshtin
UserParameter=hasp.status,haspdemo | grep "^LOCALHASP_ISHASP" | sed "s/^.* \(\-\?*\)$/\1/g"
Kjo do të lejojë komandën të mbledhë një vlerë numerike në fushën LOCALHASP_ISHASP. Në vetë zabbix, gjithçka është shtuar tashmë në mënyrë primitive, ne krijojmë artikull për hostin ose shabllonin e dëshiruar, si lloji tregojnë agjenti zabbix, specifikoni si parametër kyç hasp.statusi. Lloji i vlerës - noton. Nëse dëshironi, ne krijojmë një shkas me të cilin do të merrni një letër ose SMS që çelësi nuk funksionon. Është më mirë ta konfiguroni këtë shkas në atë mënyrë që të kërkojë të paktën 2 goditje dhe të mbulojë kohën e kërkuar nga skripti i rikuperimit automatik i përshkruar më sipër, përndryshe do të shfaqen mesazhe të rreme për problemet me çelësin.
Me cilësimet e sakta, vetëm nëse çelësi nuk funksionon plotësisht, do të merrni një njoftim për problemet.
Bonus
Doli të ishte një surprizë për mua, por shumë njerëz me të vërtetë nuk e dinë se është e mundur të detyrohen pjesët e klientit 1C të kërkojnë çelësa në adresat IP të specifikuara duke përdorur një lidhje TCP ose UDP. Në të vërtetë, shumë njerëz vendosin infrastrukturën e tyre në mënyrë që çdo domen transmetimi të ketë një numër të mjaftueshëm çelësash. Kjo është egërsi. Për ata që nuk e dinë ende, këtu është një udhëzues i shpejtë:Për të kontrolluar aksesin në çelësin hasp, ekziston një skedar nethasp.ini në klient. Ndodhet në dosjen \conf të drejtorisë 1C. Ne jemi të interesuar për seksionin Në këtë seksion, ne duhet të çkomentojmë ose të krijojmë opsionet e mëposhtme:
- NH_SERVER_ADDR. Këtu ne specifikojmë një listë të emrave DNS ose adresave IP të serverëve me një menaxher licence të ndarë me presje.
- NH_USE_BROADCAST. Vendosni vlerën në Disabled.
- NH_TCPIP_METHOD. Metoda e parazgjedhur është UDP. Ju mund të ndryshoni në TCP, por në përgjithësi nuk ka nevojë serioze për këtë.
Një pikë tjetër në lidhje me shfaqjen e çelësave në monitorin aladdin. Në kundërshtim me besimin popullor, licencat falas nuk janë vetëm ato licenca që nuk përdoren në monitorin aladdin, por edhe ato që kanë 0 në fushën Timeout. Vlerat zakonisht zhduken brenda 36 orëve, por licencat ende konsiderohen të lira.