Všichni vývojáři 1C tak či onak úzce spolupracují se službami IT a přímo se správci systému. Tato interakce ale neprobíhá vždy hladce. Rád bych vám o tom řekl několik vtipných historek.
Vysokorychlostní komunikační kanál
Většina našich klientů jsou velké holdingy s vlastními velkými IT odděleními. A za záložní kopie informačních databází jsou obvykle zodpovědní klienti specialisté. Existují ale i relativně malé organizace. Speciálně pro ně máme službu, podle které na sebe bereme všechny záležitosti související se zálohováním všeho 1C. To je společnost, o které budeme hovořit v tomto příběhu.
Na podporu 1C přišel nový klient a mimo jiné smlouva obsahovala klauzuli, že jsme zodpovědní za zálohy, ačkoli oni měli svého vlastního správce systému. Databáze klient-server, MS SQL jako DBMS. Poměrně standardní situace, ale stále tu byla jedna nuance: hlavní základna byla poměrně velká, ale měsíční nárůst byl velmi malý. To znamená, že databáze obsahovala mnoho historických dat. S ohledem na tuto funkci jsem nastavil plány údržby záloh následovně: každou první sobotu v měsíci byla vytvořena úplná záloha, která byla poměrně těžká, pak byla každou noc vytvořena rozdílová kopie - relativně malý svazek a kopie transakčního protokolu každou hodinu. Kromě toho byly úplné a rozdílové kopie nejen zkopírovány do síťového zdroje, ale také dodatečně nahrány na náš FTP server. Toto je povinný požadavek při poskytování této služby.
To vše se podařilo nakonfigurovat, uvést do provozu a celkově fungovalo bez poruch.
Ale o pár měsíců později se v této organizaci změnil správce systému. Nový správce systému začal postupně přestavovat firemní IT infrastrukturu v souladu s moderními trendy. Zejména se objevila virtualizace, police na disky, přístup byl blokován všude a všechno atd., což se v obecném případě samozřejmě nemůže radovat. Ale ne vždy pro něj šlo vše hladce, často byly problémy s výkonem 1C, což způsobilo určité neshody a nedorozumění s naší podporou. Také je třeba poznamenat, že náš vztah s ním byl obecně dost chladný a poněkud napjatý, což jen zvyšovalo míru napětí v případě jakýchkoliv problémů.
Jednoho rána se ale ukázalo, že server tohoto klienta je nedostupný. Zavolal jsem správci systému, abych zjistil, co se stalo, a jako odpověď jsem dostal něco jako „Náš server spadl, pracujeme na tom, není to na vás.“ No, je dobře, že fungují. To znamená, že situace je pod kontrolou. Po obědě znovu volám a místo podráždění už cítím v adminově hlase únavu a apatii. Snažím se přijít na to, co se stalo, a můžeme s něčím pomoci? Výsledkem rozhovoru bylo následující:
Přesunul server do nového úložného systému s nově sestaveným raidem. Něco se ale pokazilo a o pár dní později se tento nájezd bezpečně zhroutil. Zda vyhořel řadič nebo se něco stalo s disky, si přesně nepamatuji, ale všechny informace byly nenávratně ztraceny. A hlavní bylo, že na stejném diskovém poli při různých migracích skončil i síťový prostředek se zálohami. To znamená, že byla ztracena jak samotná produktivní databáze, tak všechny její záložní kopie. A není jasné, co teď dělat.
Uklidni se, říkám. Máme vaši noční zálohu. V reakci na to nastalo ticho, kterým jsem si uvědomil, že jsem právě zachránil život jednomu muži. Začneme diskutovat o tom, jak přenést tuto kopii na nový, nově nasazený server. Ale i zde nastal problém.
Pamatujete si, když jsem řekl, že plná záloha byla poměrně velká? Ne nadarmo jsem to dělal jednou za měsíc v sobotu. Faktem je, že společnost byla malým závodem, který se nacházel daleko za městem a jejich internet byl velmi podobný. V pondělí ráno, tedy o víkendu, se tuto kopii sotva podařilo nahrát na náš FTP server. Nedalo se ale čekat den nebo dva, než se naloží v opačném směru. Po několika neúspěšných pokusech o přenos souboru administrátor vyndal pevný disk přímo z nového serveru, našel někde auto s řidičem a rychle spěchal do naší kanceláře, naštěstí jsme stále ve stejném městě.
Zatímco stáli v naší serverovně a čekali na zkopírování souborů, setkali jsme se poprvé takříkajíc „osobně“, vypili jsme šálek kávy a povídali si v neformálním prostředí. Soucítil jsem s jeho zármutkem a poslal jsem ho zpět s plným šroubem záloh a narychlo obnovil zastavenou práci společnosti.
Následně byly všechny naše požadavky na IT oddělení velmi rychle vyřešeny a již nevznikaly neshody.
Kontaktujte správce systému
Jednou, po velmi dlouhou dobu, jsem nemohl publikovat 1C pro webový přístup přes IIS pro jednoho klienta. Vypadalo to jako obyčejný úkol, ale neexistoval způsob, jak vše zprovoznit. Místní správci systému se zapojili a vyzkoušeli různá nastavení a konfigurační soubory. 1C na webu normálně nechtělo nijak fungovat. Něco nebylo v pořádku, buď se zásadami zabezpečení domény, nebo s místním sofistikovaným firewallem nebo bůhví co ještě. V N-té iteraci mi admin pošle odkaz se slovy:
- Zkuste to znovu pomocí těchto pokynů. Vše je tam dost podrobně popsáno. Pokud to nepomůže, napište autorovi tohoto webu, možná vám pomůže.
"Ne," říkám, "to nepomůže."
- Proč ne?
— Jsem autorem těchto stránek... (
Ve výsledku jsme to bez problémů spustili na Apache. IIS nebyl nikdy poražen.
O úroveň hlouběji
Měli jsme klienta – malý výrobní podnik. Měli server, jakousi „klasiku“ 3 v 1: terminálový server + aplikační server + databázový server. Pracovaly v nějaké oborově specifické konfiguraci založené na UPP, bylo tam asi 15-20 uživatelů a výkon systému v zásadě vyhovoval všem.
Jak čas plynul, vše fungovalo víceméně stabilně. Pak ale Evropa uvalila na Rusko sankce, v důsledku čehož Rusové začali nakupovat především produkty domácí výroby a byznys pro tuto společnost šel prudce nahoru. Počet uživatelů se zvýšil na 50-60 lidí, byla otevřena nová pobočka a odpovídajícím způsobem se zvýšil i tok dokumentů. A nyní se současný server již nedokázal vyrovnat s prudce zvýšeným zatížením a 1C začal, jak se říká, „zpomalovat“. Ve špičce se dokumenty zpracovávaly několik minut, docházelo k chybám blokování, dlouho se otevíraly formuláře a celá další sada souvisejících služeb. Místní správce systému všechny problémy oprášil a řekl: "Toto je vaše 1C, přijdete na to." Opakovaně jsme navrhovali provést výkonnostní audit systému, ale k samotnému auditu nikdy nedošlo. Klient jednoduše požádal o doporučení, jak problémy vyřešit.
Dobře, sedl jsem si a napsal poměrně dlouhý dopis o nutnosti oddělit role terminálového serveru a aplikačního serveru s DBMS (což jsme v zásadě již mnohokrát řekli). Psal jsem o DFSS na terminálových serverech, o sdílené paměti, poskytl odkazy na autoritativní zdroje a dokonce navrhl některé možnosti vybavení. Tento dopis se dostal k mocným ve společnosti, vrátil se zpět do IT oddělení s usnesením „Implementovat“ a ledy byly obecně prolomeny.
Po nějaké době mi admin pošle IP adresu nového serveru a přihlašovací údaje. Říká, že tam jsou nasazeny komponenty serveru MS SQL a 1C a databáze je třeba přenést, ale zatím pouze na server DBMS, protože se objevily problémy s klíči 1C.
Přišel jsem, skutečně všechny služby běžely, server nebyl příliš výkonný, ale dobře, myslím, že je to lepší než nic. Prozatím převedu databáze, abych nějak odlehčil současnému serveru. Všechny přesuny jsem absolvoval ve smluvený čas, ale situace se nezměnila – stále stejné výkonnostní problémy. Je to samozřejmě zvláštní, no, registrujme databáze v clusteru 1C a uvidíme.
Uplynulo několik dní, klíče nebyly přeneseny. Zajímalo by mě, v čem je problém, vše se zdá být jednoduché - vyndat to z jednoho serveru, zapojit do druhého, nainstalovat ovladač a hotovo. Administrátor zareaguje tak, že se rozčiluje a říká něco o přesměrování portů, virtuálním serveru a tak dále.
Hmm... Virtuální server? Zdá se, že žádná virtualizace nikdy nebyla a nikdy nebyla... Vzpomínám si na poměrně známý problém s nemožností přeposlat klíč 1C serveru na virtuální stroj na Hyper-V ve Windows Server 2008. A zde začínají se ve mně rodit nějaké podezření...
Otevřu správce serveru - Role - objevila se nová role - Hyper-V. Jdu do správce Hyper-V, uvidím jeden virtuální stroj, připojím se... A skutečně... Náš nový databázový server...
No a co? Pokyny úřadů a má doporučení byly splněny, role byly odděleny. Úkol lze uzavřít.
Po nějaké době nastala nyní krize, nová pobočka musela být uzavřena, zátěž se snížila a výkon systému se stal víceméně snesitelným.
Samozřejmě nemohli předat klíč serveru virtuálnímu počítači. Výsledkem bylo, že vše zůstalo tak, jak je: terminálový server + cluster 1C na fyzickém stroji, databázový server tam na virtuálním.
A bylo by hezké, kdyby to byl nějaký druh sharashkinovy kanceláře. Takže ne. Známá firma, jejíž produkty pravděpodobně znáte a viděli jste v příslušných odděleních všech Lentas a Auchans.
Plán dovolené na pevném disku
Velký holding s ambiciózními plány na převzetí světa opět koupil malou společnost s cílem začlenit ji do své megakorporace. Ve všech divizích tohoto holdingu uživatelé pracují ve vlastních databázích, ale s identickou konfigurací. A tak jsme zahájili malý projekt na zařazení nové jednotky do tohoto systému.
V první řadě je nutné nasadit produkční a testovací databáze. Vývojář obdržel data připojení, přihlásil se na server, vidí nainstalovaný MS SQL, 1C server, vidí 2 logické jednotky: jednotku „C“ s kapacitou 250 gigabajtů a jednotku „D“ s kapacitou 1 terabajt. No, „C“ je systém, „D“ je pro data, vývojář se logicky rozhodne a nasadí tam všechny databáze. Dokonce jsem pro každý případ nastavil plány údržby včetně zálohování (i když za to neneseme odpovědnost). Pravda, zálohy byly přidány sem do „D“. Do budoucna se plánovalo jeho překonfigurování na nějaký samostatný síťový zdroj.
Projekt byl zahájen, konzultanti poskytli školení o práci v novém systému, přenesly se zbytky, provedla drobná drobná vylepšení a uživatelé začali pracovat v nové informační základně.
Všechno šlo dobře až do jednoho pondělního rána, kdy se zjistilo, že chybí databázový disk. Na serveru prostě není žádné „D“ a to je vše.
Další vyšetřování odhalilo toto: tento „server“ byl ve skutečnosti pracovním počítačem místního správce systému. Pravda, stále měl serverový OS. Osobní USB disk tohoto správce byl připojen k serveru. A tak správce odjel na dovolenou a vzal s sebou svůj šroubek s cílem napumpovat do něj filmy na cestu.
Díky bohu se mu nepodařilo smazat databázové soubory a podařilo se mu obnovit produktivní databázi.
Je pozoruhodné, že všichni byli obecně spokojeni s výkonem systému umístěného na USB disku. Nikdo si nestěžoval na nějaký neuspokojivý výkon 1C. Teprve později holding zahájil megaprojekt na převedení všech informačních databází na jediné centralizované místo se superservery, úložnými systémy za milion+ rublů, sofistikovanými hypervizory a nesnesitelnými 1C brzdami ve všech pobočkách.
Ale to je úplně jiný příběh...
Zdroj: www.habr.com