Minden 1C fejlesztő ilyen vagy olyan módon szorosan együttműködik az IT-szolgáltatásokkal és közvetlenül a rendszergazdákkal. De ez az interakció nem mindig megy zökkenőmentesen. Erről szeretnék elmesélni néhány vicces történetet.
Nagy sebességű kommunikációs csatorna
Ügyfeleink többsége nagyvállalat, saját nagy informatikai részleggel. Az ügyfélspecialisták pedig általában az információs adatbázisok biztonsági másolataiért felelősek. De vannak viszonylag kis szervezetek is. Kifejezetten számukra van egy szolgáltatásunk, amely szerint minden 1C biztonsági mentéssel kapcsolatos minden kérdést megoldunk. Erről a cégről fogunk beszélni ebben a történetben.
Új kliens érkezett az 1C támogatására, és többek között a szerződésben volt egy kitétel, hogy mi vagyunk a felelősek a biztonsági mentésekért, bár nekik saját rendszergazdájuk volt. Kliens-szerver adatbázis, MS SQL mint DBMS. Meglehetősen szokásos helyzet, de még mindig volt egy árnyalat: a fő bázis elég nagy volt, de a havi növekedés nagyon kicsi. Azaz az adatbázis sok történelmi adatot tartalmazott. Ezt a funkciót figyelembe véve a következőképpen állítottam össze a biztonsági mentési karbantartási terveket: minden hónap első szombatján teljes biztonsági mentés készült, elég nehéz volt, majd minden este készült egy differenciálmásolat - viszonylag kis kötet, és egy másolat a tranzakciós naplóból óránként. Sőt, a teljes és differenciált másolatokat nem csak egy hálózati erőforrásra másoltuk, hanem az FTP szerverünkre is feltöltöttük. Ez kötelező követelmény a szolgáltatás nyújtásakor.
Mindezt sikeresen konfigurálták, üzembe helyezték és általában hiba nélkül működtek.
Néhány hónappal később azonban megváltozott a rendszergazda ebben a szervezetben. Az új rendszergazda fokozatosan, a modern trendeknek megfelelően kezdte átépíteni a cég informatikai infrastruktúráját. Különösen megjelent a virtualizáció, a lemezpolcok, mindenhol és mindenhol blokkolták a hozzáférést, stb., amelyek általában természetesen nem örülhetnek. De a dolgok nem mindig mentek simán számára; gyakran voltak problémák az 1C teljesítményével, ami nézeteltéréseket és félreértéseket okozott a támogatásunkkal. Azt is meg kell jegyezni, hogy a kapcsolatunk vele általában meglehetősen hideg és kissé feszült volt, ami csak növelte a feszültség mértékét bármilyen felmerülő probléma esetén.
Egy reggel azonban kiderült, hogy ennek az ügyfélnek a szervere nem elérhető. Felhívtam a rendszergazdát, hogy megtudjam, mi történt, és valami olyasmit kaptam, hogy „A szerverünk összeomlott, dolgozunk rajta, nem rajtad múlik.” Hát jó, hogy működnek. Ez azt jelenti, hogy a helyzet ellenőrzés alatt áll. Ebéd után újra visszahívom, és ingerültség helyett már fáradtságot és apátiát érzek az adminisztrátor hangjában. Megpróbálom kideríteni, mi történt, és tudunk-e segíteni valamit? A beszélgetés eredményeként a következők derültek ki:
Egy újonnan összeállított raid segítségével új tárolórendszerbe helyezte át a szervert. De valami elromlott, és néhány nappal később ez a razzia biztonságosan összeomlott. Hogy kiégett-e a vezérlő, vagy történt valami a lemezekkel, arra nem emlékszem pontosan, de minden információ helyrehozhatatlanul elveszett. A lényeg pedig az volt, hogy a biztonsági mentésekkel ellátott hálózati erőforrás is ugyanarra a lemeztömbre került a különböző migrációk során. Vagyis maga a produktív adatbázis és annak minden biztonsági másolata is elveszett. És nem világos, hogy most mit kell tenni.
Nyugodj meg, mondom. Megvan az éjszakai biztonsági mentésed. Válaszul csend lett, ami által rájöttem, hogy most mentettem meg egy ember életét. Megvitatjuk, hogyan vihetjük át ezt a példányt egy új, újonnan telepített kiszolgálóra. De itt is felmerült egy probléma.
Emlékszel, amikor azt mondtam, hogy a teljes biztonsági másolat elég nagy? Nem hiába csináltam havonta egyszer szombaton. A helyzet az, hogy a cég egy kis üzem volt, amely messze a városon kívül volt, és az internet nagyon jó volt. Hétfő reggelre, vagyis a hétvégén ezt a példányt alig sikerült feltölteni az FTP szerverünkre. De nem lehetett várni egy-két napot, amíg az ellenkező irányba töltődik. Többszöri sikertelen fájlátviteli kísérlet után az adminisztrátor közvetlenül az új szerverről kivette a merevlemezt, valahol talált egy autót sofőrrel és gyorsan az irodánkba rohant, szerencsére még mindig ugyanabban a városban vagyunk.
Amíg a szerverszobánkban álltak, és várták a fájlmásolást, mi először találkoztunk úgymond „személyesen”, ittunk egy csésze kávét, és kötetlen környezetben beszélgettünk. Együtt éreztem a gyászát, és egy teljes csavarral visszaküldtem, sietve helyreállítva a cég leállt munkáját.
Ezt követően az informatikai részleghez intézett összes kérésünket nagyon gyorsan megoldották, és nem merült fel több nézeteltérés.
Forduljon a rendszergazdához
Egyszer nagyon hosszú ideig nem tudtam közzétenni az 1C-t az IIS-en keresztüli webes eléréshez egyetlen ügyfél számára. Közönséges feladatnak tűnt, de nem lehetett mindent beindítani. A helyi rendszergazdák bekapcsolódtak, és különféle beállításokat és konfigurációs fájlokat próbáltak ki. Az 1C a weben általában semmilyen módon nem akart működni. Valami nem stimmelt, vagy a tartomány biztonsági szabályzatával, vagy a helyi kifinomult tűzfallal, vagy Isten tudja, mi mással. Az N-edik iterációnál az adminisztrátor küld nekem egy linket a következő szavakkal:
- Próbálkozzon újra ezen utasítások szerint. Ott elég részletesen le van írva minden. Ha nem megy, írj az oldal szerzőjének, hátha tud segíteni.
– Nem – mondom –, ez nem fog segíteni.
- Miért?
— Én vagyok ennek az oldalnak a szerzője... (
Ennek eredményeként minden probléma nélkül elindítottuk Apache-on. Az IIS-t soha nem győzték le.
Egy szinttel mélyebbre
Volt egy ügyfelünk - egy kis gyártó cég. Volt egy szerverük, amolyan „klasszikus” 3 az 1-ben: terminálszerver + alkalmazásszerver + adatbázisszerver. Valami iparág-specifikus UPP-n alapuló konfigurációban dolgoztak, kb 15-20 felhasználó volt, és a rendszer teljesítménye elvileg mindenkinek megfelelt.
Ahogy telt az idő, többé-kevésbé stabilan működött minden. De aztán Európa szankciókat vezetett be Oroszország ellen, aminek következtében az oroszok elsősorban hazai termelésű termékeket kezdtek vásárolni, és ennek a cégnek az üzlete meredeken emelkedett. A felhasználók száma 50-60 főre nőtt, új fiók nyílt, és ennek megfelelően nőtt a dokumentumforgalom. És most a jelenlegi szerver már nem tudott megbirkózni az élesen megnövekedett terheléssel, és az 1C, ahogy mondják, elkezdett „lassulni”. Csúcsidőben több percig tartó iratok feldolgozása zajlott, blokkolási hibák, nyomtatványok hosszú ideig tartó megnyitása és a kapcsolódó szolgáltatások egész csokora. A helyi rendszergazda elhárította az összes problémát, mondván: „Ez az Ön 1C-je, majd kitalálja.” Többször javasoltuk a rendszer teljesítmény-ellenőrzésének lefolytatását, de ez magától az ellenőrzésig nem jutott el. Az ügyfél egyszerűen ajánlásokat kért a problémák megoldására.
Nos, leültem és írtam egy elég hosszadalmas levelet arról, hogy el kell különíteni a terminálszerver és az alkalmazásszerver szerepét a DBMS-sel (amit elvileg már sokszor elmondtunk). Írtam a DFSS-ről a terminálszervereken, a megosztott memóriáról, hivatkozásokat adtam hiteles forrásokhoz, és még a berendezésekhez is javasoltam néhány lehetőséget. Ez a levél eljutott a cég hatalmába, visszakerült az informatikai osztályra a „Végrehajtás” határozatokkal, és a jég általában megtört.
Egy idő után az adminisztrátor elküldi nekem az új szerver IP-címét és a bejelentkezési adatokat. Elmondja, hogy ott MS SQL és 1C szerver komponensek vannak telepítve, az adatbázisokat át kell vinni, de egyelőre csak a DBMS szerverre, mivel az 1C kulcsokkal adódott néhány probléma.
Bejöttem, valóban minden szolgáltatás futott, a szerver nem volt túl erős, de oké, szerintem jobb, mint a semmi. Egyelőre átviszem az adatbázisokat, hogy valahogy tehermentesítsem a jelenlegi szervert. Az összes átutalást a megbeszélt időpontban teljesítettem, de a helyzet nem változott - továbbra is ugyanazok a teljesítményproblémák. Furcsa persze, nos, regisztráljuk az adatbázisokat az 1C klaszterbe, és meglátjuk.
Eltelt néhány nap, a kulcsokat nem adták át. Kíváncsi vagyok, mi a probléma, minden egyszerűnek tűnik – vegye ki az egyik szerverről, csatlakoztassa a másikhoz, telepítse az illesztőprogramot és kész. Az adminisztrátor úgy válaszol, hogy dumál, és mond valamit a porttovábbításról, egy virtuális szerverről stb.
Hmm... Virtuális szerver? Úgy tűnik, soha nem volt virtualizáció, és nem is volt... Emlékszem egy meglehetősen jól ismert problémára, amely a Windows Server 1 rendszerben a Hyper-V-n lévő virtuális gépre való 2008C kiszolgálókulcs továbbításának lehetetlenségével kapcsolatos. kezd kialakulni bennem valami gyanakvás...
Megnyitom a szerverkezelőt - Roles - megjelent egy új szerepkör - Hyper-V. Megyek a Hyper-V menedzserhez, megnézek egy virtuális gépet, csatlakozom... És valóban... Az új adatbázis-szerverünk...
És akkor mi van? A hatósági utasítások, javaslataim megvalósultak, a szerepek szétválasztásra kerültek. A feladat lezárható.
Egy idő után beállt a mostani válság, be kellett zárni az új fiókot, csökkent a terhelés, a rendszer teljesítménye többé-kevésbé elviselhetővé vált.
Nos, természetesen nem tudták továbbítani a szerverkulcsot a virtuális gépre. Ennek eredményeként minden maradt a régiben: terminál szerver + 1C klaszter egy fizikai gépen, adatbázis szerver ott egy virtuálison.
És jó lenne, ha ez valami Sharashkin iroda lenne. Szóval nem. Egy jól ismert cég, amelynek termékeit valószínűleg ismeri és látta az összes Lentas és Auchan illetékes osztályán.
Merevlemezes vakáció ütemezése
Egy nagy holding ambiciózus tervekkel, hogy meghódítsa a világot, ismét vásárolt egy kis céget azzal a céllal, hogy beépítse megavállalatába. A holding minden részlegében a felhasználók saját adatbázisukban dolgoznak, de azonos konfigurációval. Ezért elkezdtünk egy kis projektet, hogy egy új egységet építsünk be ebbe a rendszerbe.
Mindenekelőtt éles és tesztadatbázisok telepítése szükséges. A fejlesztő megkapta a csatlakozási adatokat, bejelentkezik a szerverre, látja az MS SQL telepítését, az 1C szervert, 2 logikai meghajtót lát: a „C” meghajtót 250 gigabájt kapacitással és a „D” meghajtót, amelynek kapacitása 1 terabájt. Nos, "C" a rendszer, "D" az adatoké, a fejlesztő logikusan dönti el és telepíti az összes adatbázist. Még karbantartási terveket is felállítottam, beleértve a biztonsági mentést is, minden esetre (bár ezért nem vagyunk felelősek). Igaz, a biztonsági mentések ide kerültek a „D”-be. A jövőben azt tervezték, hogy átkonfigurálják valamilyen külön hálózati erőforrásra.
A projekt elindult, a tanácsadók képzést tartottak az új rendszerben való munkavégzésről, a maradékokat átvitték, kisebb-nagyobb fejlesztéseket hajtottak végre, és a felhasználók elkezdtek dolgozni az új információs bázisban.
Minden rendben ment egészen egy hétfő reggelig, amikor kiderült, hogy hiányzik az adatbázislemez. Egyszerűen nincs "D" a szerveren, és ennyi.
A további vizsgálat során kiderült: ez a „szerver” valójában egy helyi rendszergazda munkagépe volt. Igaz, még volt szerver operációs rendszere. Ennek az adminisztrátor személyes USB-meghajtója csatlakoztatva volt a szerverhez. Így hát az adminisztrátor nyaralni ment, magával vitte a csavarját, azzal a céllal, hogy filmeket töltsön bele az útra.
Hála Istennek, nem sikerült törölnie az adatbázis fájlokat, és sikerült visszaállítania a produktív adatbázist.
Figyelemre méltó, hogy általában mindenki elégedett volt az USB-meghajtón található rendszer teljesítményével. Senki sem panaszkodott az 1C nem kielégítő teljesítményére. A holding csak később kezdett bele egy megaprojektbe, hogy az összes információs adatbázist egyetlen központosított oldalra helyezzék át szuperszerverekkel, több millió rubelért tároló rendszerekkel, kifinomult hipervizorokkal és elviselhetetlen 1C fékekkel minden ágban.
De ez egy teljesen más történet...
Forrás: will.com