Vsi razvijalci 1C na tak ali drugačen način tesno sodelujejo z IT storitvami in neposredno s sistemskimi skrbniki. Toda ta interakcija ne poteka vedno gladko. O tem bi vam rad povedal nekaj smešnih zgodb.
Visokohitrostni komunikacijski kanal
Večina naših strank so veliki holdingi s svojimi velikimi IT oddelki. In strokovnjaki za stranke so običajno odgovorni za varnostne kopije informacijskih baz podatkov. Obstajajo pa tudi relativno majhne organizacije. Posebej za njih imamo storitev, v skladu s katero prevzamemo vsa vprašanja v zvezi z varnostnim kopiranjem vsega 1C. To je podjetje, o katerem bomo govorili v tej zgodbi.
Prišla je nova stranka za podporo 1C in med drugim je bila v pogodbi zapisana klavzula, da smo odgovorni za varnostne kopije, čeprav so imeli zaposlenega svojega sistemskega skrbnika. Baza podatkov odjemalec-strežnik, MS SQL kot DBMS. Precej standardna situacija, vendar je bila še ena niansa: glavna baza je bila precej velika, vendar je bilo mesečno povečanje zelo majhno. To pomeni, da je zbirka podatkov vsebovala veliko zgodovinskih podatkov. Ob upoštevanju te lastnosti sem načrte vzdrževanja varnostne kopije postavil takole: vsako prvo soboto v mesecu je bila izdelana popolna varnostna kopija, ki je bila precej težka, nato pa je bila vsak večer narejena diferencialna kopija - razmeroma majhen obseg in kopija dnevnika transakcij vsako uro. Poleg tega polne in diferencialne kopije niso bile samo kopirane v omrežni vir, ampak tudi dodatno naložene na naš strežnik FTP. To je obvezna zahteva pri zagotavljanju te storitve.
Vse to je bilo uspešno konfigurirano, zagnano in na splošno je delovalo brez napak.
Toda nekaj mesecev kasneje se je sistemski skrbnik v tej organizaciji spremenil. Novi sistemski skrbnik je začel postopoma prenavljati informacijsko infrastrukturo podjetja v skladu s sodobnimi trendi. Zlasti se je pojavila virtualizacija, diskovne police, dostop je bil blokiran povsod in vse itd., Kar se v splošnem seveda ne more veseliti. Vendar mu ni šlo vedno gladko, pogosto so bile težave z delovanjem 1C, kar je povzročilo nekaj nesoglasij in nesporazumov z našo podporo. Prav tako je treba opozoriti, da je bil naš odnos z njim na splošno precej hladen in nekoliko napet, kar je samo še povečalo stopnjo napetosti ob morebitnih težavah.
Toda nekega jutra se je izkazalo, da strežnik te stranke ni bil na voljo. Poklical sem skrbnika sistema, da bi izvedel, kaj se je zgodilo, in kot odgovor prejel nekaj takega: "Naš strežnik se je zrušil, mi delamo na tem, ne na vas." No, še dobro, da delajo. To pomeni, da je situacija pod nadzorom. Po kosilu ponovno pokličem in namesto razdraženosti v glasu administratorja že čutim utrujenost in apatijo. Poskušam ugotoviti, kaj se je zgodilo in ali lahko kako pomagamo? Kot rezultat pogovora je nastalo naslednje:
Strežnik je preselil v nov sistem za shranjevanje z novo sestavljenim raidom. Toda nekaj je šlo narobe in nekaj dni kasneje je ta napad varno propadel. Ali je krmilnik zgorel ali se je kaj zgodilo z diski, se ne spomnim natančno, vendar so bile vse informacije nepovratno izgubljene. In glavno je bilo, da je omrežni vir z varnostnimi kopijami med različnimi selitvami tudi končal na istem diskovnem polju. To pomeni, da je bila izgubljena sama produktivna baza podatkov in vse njene varnostne kopije. In zdaj ni jasno, kaj storiti.
Pomiri se, pravim. Imamo vašo nočno rezervo. V odgovor je bila tišina, po kateri sem spoznal, da sem človeku pravkar rešil življenje. Začnemo razpravljati o tem, kako to kopijo prenesti na nov, na novo nameščen strežnik. A tudi tu se je pojavila težava.
Se spomnite, ko sem rekel, da je bila popolna varnostna kopija precej velika? Nisem zaman to počel enkrat na mesec ob sobotah. Dejstvo je, da je bilo podjetje majhna tovarna, ki se je nahajala daleč izven mesta in njihov internet je bil zelo tako. Do ponedeljka zjutraj, torej čez vikend, se je ta izvod komaj uspel naložiti na naš FTP strežnik. Ni pa bilo možnosti čakati dan ali dva, da se naloži v obratni smeri. Po več neuspešnih poskusih prenosa datoteke je administrator vzel trdi disk direktno iz novega strežnika, nekje našel avto z voznikom in hitro odhitel v našo pisarno, na srečo smo še vedno v istem mestu.
Medtem ko sta stala v naši strežniški sobi in čakala na kopiranje datotek, sva se tako rekoč »osebno« prvič srečala, spila kavo in se pogovarjala v neformalnem okolju. Sočustvoval sem z njegovo žalostjo in ga poslal nazaj s polnim vijakom varnostnih kopij, ki je naglo obnovil ustavljeno delo podjetja.
V nadaljevanju so bile vse naše zahteve do IT službe rešene zelo hitro in do nesoglasij ni prišlo več.
Obrnite se na skrbnika sistema
Enkrat zelo dolgo nisem mogel objaviti 1C za spletni dostop prek IIS za enega odjemalca. Zdelo se je kot običajna naloga, vendar ni bilo možnosti, da bi vse pognali v tek. Lokalni sistemski skrbniki so se vključili in preizkusili različne nastavitve in konfiguracijske datoteke. 1C na spletu običajno nikakor ni hotel delovati. Nekaj je bilo narobe, bodisi z varnostnimi politikami domene, bodisi z lokalnim sofisticiranim požarnim zidom ali Bog ve kaj še. Pri N-ti ponovitvi mi skrbnik pošlje povezavo z besedami:
- Poskusite znova z uporabo teh navodil. Tam je vse zelo podrobno opisano. Če ne gre, pišite avtorju te strani, mogoče lahko pomaga.
"Ne," rečem, "ne bo pomagalo."
Zakaj?
— Jaz sem avtor te strani... (
Posledično smo ga brez težav zagnali na Apache. IIS ni bil nikoli poražen.
En nivo globlje
Imeli smo stranko - majhno proizvodno podjetje. Imeli so strežnik, nekakšno “klasično” 3 v 1: terminalski strežnik + aplikacijski strežnik + podatkovni strežnik. Delali so v neki panožni konfiguraciji, ki je temeljila na UPP, bilo je približno 15-20 uporabnikov in delovanje sistema je načeloma vsem ustrezalo.
Sčasoma je vse delovalo bolj ali manj stabilno. Toda nato je Evropa uvedla sankcije proti Rusiji, zaradi česar so Rusi začeli kupovati predvsem domače izdelke, poslovanje tega podjetja pa je šlo strmo navzgor. Število uporabnikov se je povečalo na 50-60 ljudi, odprli so novo poslovalnico, temu primerno se je povečal tudi pretok dokumentov. In zdaj se trenutni strežnik ni mogel več spopadati z močno povečano obremenitvijo in 1C se je začel, kot pravijo, "upočasnjevati". V konicah so bili dokumenti obdelani več minut, prihajalo je do napak pri blokiranju, odpiranje obrazcev je trajalo dolgo časa in še cel šopek povezanih storitev. Lokalni sistemski skrbnik je odvrnil vse težave z besedami: "To je vaš 1C, sami boste ugotovili." Večkrat smo predlagali izvedbo revizije delovanja sistema, a do same revizije nikoli ni prišlo. Stranka je preprosto prosila za priporočila, kako odpraviti težave.
No, sedel sem in napisal precej dolgo pismo o potrebi po ločitvi vlog terminalskega strežnika in aplikacijskega strežnika z DBMS (kar smo načeloma že večkrat povedali). Pisal sem o DFSS na terminalskih strežnikih, o skupnem pomnilniku, zagotovil povezave do verodostojnih virov in celo predlagal nekaj možnosti za opremo. To pismo je doseglo vodilne v podjetju, se vrnilo v IT oddelek z resolucijo »Izvedi« in led je bil na splošno prebit.
Čez nekaj časa mi skrbnik pošlje naslov IP novega strežnika in poverilnice za prijavo. Pravi, da so tam nameščene strežniške komponente MS SQL in 1C, baze podatkov pa je treba prenesti, vendar za zdaj le na strežnik DBMS, saj so se pojavile težave s ključi 1C.
Prišel sem, res, vse storitve so delovale, strežnik ni bil zelo zmogljiv, ampak ok, mislim, da je bolje kot nič. Zaenkrat bom prenesel baze podatkov, da nekako razbremenim trenutni strežnik. Vse nakazila sem opravil v dogovorjenem času, vendar se situacija ni spremenila - še vedno iste težave pri izvedbi. Seveda je čudno, no, registrirajmo baze podatkov v grozd 1C in bomo videli.
Minilo je nekaj dni, ključi niso bili preneseni. Zanima me, v čem je težava, zdi se, da je vse preprosto - vzemite ga iz enega strežnika, priključite na drugega, namestite gonilnik in končali ste. Administrator se odzove tako, da se razburja in govori nekaj o posredovanju vrat, virtualnem strežniku itd.
Hmm ... Virtualni strežnik? Zdi se, da virtualizacije nikoli ni bilo in je tudi nikoli ni bilo ... Spomnim se dokaj znane težave z nezmožnostjo posredovanja ključa strežnika 1C virtualnemu stroju na Hyper-V v Windows Server 2008. In tukaj v meni se začnejo porajati neki sumi...
Odprem upravitelja strežnika - Vloge - pojavila se je nova vloga - Hyper-V. Grem v upravitelja Hyper-V, vidim en virtualni stroj, se povežem ... In res ... Naš novi strežnik baze podatkov ...
Pa kaj? Navodila pristojnih in moja priporočila so bila izvedena, vloge so bile razdeljene. Naloga se lahko zapre.
Čez nekaj časa se je zgodila zdajšnja kriza, novo podružnico so morali zapreti, obremenitev se je zmanjšala in delovanje sistema je postalo bolj ali manj znosno.
No, seveda ključa strežnika niso mogli posredovati virtualnemu stroju. Posledično je vse ostalo tako, kot je: terminalski strežnik + gruča 1C na fizičnem stroju, strežnik baze podatkov tam v virtualnem.
In lepo bi bilo, če bi bila to nekakšna šaraškinova pisarna. Torej ne. Znano podjetje, katerega izdelke verjetno poznate in ste jih videli v ustreznih oddelkih vseh Lentas in Auchans.
Počitniški urnik trdega diska
Velik holding z ambicioznimi načrti za prevzem sveta je ponovno kupil majhno podjetje s ciljem, da ga vključi v svojo megakorporacijo. V vseh oddelkih tega holdinga uporabniki delajo v svojih bazah podatkov, vendar z enako konfiguracijo. In tako smo začeli majhen projekt za vključitev nove enote v ta sistem.
Najprej je treba razmestiti produkcijske in testne baze podatkov. Razvijalec je prejel podatke o povezavi, se prijavi v strežnik, vidi nameščen MS SQL, strežnik 1C, vidi 2 logična pogona: pogon "C" s kapaciteto 250 gigabajtov in pogon "D" s kapaciteto 1 terabajta. No, "C" je sistem, "D" je za podatke, razvijalec se logično odloči in postavi vse baze podatkov tja. Nastavil sem celo načrte vzdrževanja, vključno z varnostnim kopiranjem, za vsak slučaj (čeprav za to nismo odgovorni). Res je, varnostne kopije so bile dodane tukaj v "D". V prihodnosti je bilo načrtovano, da ga ponovno konfigurirate v nek ločen omrežni vir.
Projekt se je začel, svetovalci so izvedli usposabljanje za delo v novem sistemu, prenesli so ostanke, naredili nekaj manjših manjših izboljšav in uporabniki so začeli delati v novi informacijski bazi.
Vse je šlo dobro do nekega ponedeljkovega jutra, ko so odkrili, da manjka disk z bazo podatkov. Na strežniku preprosto ni "D" in to je to.
Nadaljnja preiskava je razkrila tole: ta »strežnik« je bil pravzaprav delovni računalnik lokalnega sistemskega skrbnika. Res je, še vedno je imel strežniški OS. Osebni pogon USB tega skrbnika je bil priključen na strežnik. In tako je administrator odšel na dopust in s seboj vzel svoj vijak, s ciljem, da vanj načrpa filme za na pot.
Hvala bogu, ni uspel izbrisati datotek baze podatkov in uspel je obnoviti produktivno bazo podatkov.
Omeniti velja, da so bili vsi na splošno zadovoljni z delovanjem sistema, ki se nahaja na pogonu USB. Nihče se ni pritožil zaradi nezadovoljivega delovanja 1C. Šele pozneje je holding začel megaprojekt prenosa vseh informacijskih baz podatkov na eno samo centralizirano mesto s superstrežniki, sistemi za shranjevanje za milijon+ rubljev, sofisticiranimi hipervizorji in neznosnimi zavorami 1C v vseh podružnicah.
Ampak to je čisto druga zgodba...
Vir: www.habr.com