Svi 1C programeri na ovaj ili onaj način blisko surađuju s IT uslugama i izravno s administratorima sustava. Ali ta interakcija ne ide uvijek glatko. Htio bih vam ispričati nekoliko smiješnih priča o tome.
Komunikacijski kanal velike brzine
Većina naših klijenata su veliki holdingi sa svojim velikim IT odjelima. A stručnjaci za klijente obično su odgovorni za sigurnosne kopije baza podataka. Ali postoje i relativno male organizacije. Posebno za njih imamo uslugu prema kojoj na sebe preuzimamo sva pitanja vezana uz backup svega 1C. To je tvrtka o kojoj ćemo govoriti u ovoj priči.
Došao je novi klijent za podršku 1C i između ostalog je u ugovoru stajala klauzula da smo mi odgovorni za sigurnosne kopije, iako su oni imali svog sistem administratora. Klijent-poslužitelj baza podataka, MS SQL kao DBMS. Prilično standardna situacija, ali još uvijek je postojala jedna nijansa: glavna baza bila je prilično velika, ali mjesečni porast bio je vrlo mali. Odnosno, baza je sadržavala mnogo povijesnih podataka. Uzimajući u obzir ovu značajku, postavio sam planove održavanja sigurnosne kopije na sljedeći način: prve subote svakog mjeseca napravljena je potpuna sigurnosna kopija, bila je prilično teška, zatim je svake večeri napravljena diferencijalna kopija - relativno mali volumen i kopija dnevnika transakcija svakog sata. Štoviše, pune i diferencijalne kopije nisu samo kopirane na mrežni resurs, već su i dodatno učitane na naš FTP poslužitelj. Ovo je obavezan uvjet prilikom pružanja ove usluge.
Sve je to uspješno konfigurirano, pušteno u rad i općenito je radilo bez kvarova.
Ali nekoliko mjeseci kasnije promijenio se administrator sustava u ovoj organizaciji. Novi administrator sustava počeo je postupno obnavljati IT infrastrukturu tvrtke u skladu sa suvremenim trendovima. Konkretno, pojavila se virtualizacija, police za diskove, pristup je blokiran posvuda i sve, itd., Što se u općem slučaju, naravno, ne može ne radovati. Ali stvari mu nisu uvijek išle glatko; često je bilo problema s radom 1C, što je uzrokovalo neka neslaganja i nesporazume s našom podrškom. Također, treba napomenuti da je naš odnos s njim općenito bio prilično hladan i donekle zategnut, što je samo povećavalo stupanj napetosti u slučaju bilo kakvih problema.
Ali jednog jutra ispostavilo se da je poslužitelj ovog klijenta nedostupan. Nazvao sam administratora sustava da saznam što se dogodilo i kao odgovor dobio nešto poput "Naš server se srušio, mi radimo na tome, ne ovisi o vama." Pa dobro je da rade. To znači da je situacija pod kontrolom. Nakon ručka ponovno zovem i umjesto iritacije već osjećam umor i apatiju u glasu administratora. Pokušavam shvatiti što se dogodilo i možemo li nekako pomoći? Kao rezultat razgovora proizašlo je sljedeće:
Premjestio je poslužitelj na novi sustav pohrane s novosastavljenim raidom. Ali nešto je pošlo po zlu i nekoliko dana kasnije ova je racija sigurno propala. Da li je izgorio kontroler ili se nešto dogodilo s diskovima, ne sjećam se točno, ali sve informacije su nepovratno izgubljene. A glavna stvar je bila da je mrežni resurs sa sigurnosnim kopijama također završio na istom disku tijekom raznih migracija. To jest, izgubljena je i sama produktivna baza podataka i sve njezine sigurnosne kopije. I nije jasno što sada učiniti.
Smiri se, kažem. Imamo vašu noćnu podršku. Kao odgovor uslijedila je tišina po kojoj sam shvatio da sam jednom čovjeku upravo spasio život. Počinjemo raspravljati o tome kako prenijeti ovu kopiju na novi, novo postavljeni poslužitelj. Ali i tu se pojavio problem.
Sjećate se kada sam rekao da je puna sigurnosna kopija prilično velika? Nisam to uzalud radio jednom mjesečno subotom. Činjenica je da je tvrtka bila mala tvornica, koja se nalazila daleko izvan grada i njihov internet je bio vrlo tako-tako. Do ponedjeljka ujutro, odnosno tijekom vikenda, ova se kopija jedva uspjela uploadati na naš FTP server. Ali nije bilo šanse čekati dan-dva da se učita u suprotnom smjeru. Nakon nekoliko neuspješnih pokušaja prijenosa datoteke, administrator je izvadio hard disk direktno s novog servera, pronašao negdje auto s vozačem i brzo odjurio u naš ured, srećom još smo u istom gradu.
Dok su oni stajali u našoj poslužiteljskoj sobi i čekali da se kopiraju datoteke, prvi put smo se sreli, da tako kažem, “osobno”, popili kavu i popričali u neformalnom okruženju. Suosjećao sam s njegovom tugom i poslao ga natrag s punim rezervnim kopijama, na brzinu obnovivši zaustavljeni rad tvrtke.
Naknadno su svi naši zahtjevi upućeni IT službi vrlo brzo riješeni i više nije bilo nikakvih nesuglasica.
Kontaktirajte svog administratora sustava
Jednom, jako dugo, nisam mogao objaviti 1C za pristup webu putem IIS-a za jednog klijenta. Činilo se kao običan zadatak, ali nije bilo načina da se sve pokrene. Uključili su se lokalni administratori sustava i isprobali različite postavke i konfiguracijske datoteke. 1C na webu obično nije htio raditi ni na koji način. Nešto nije bilo u redu, ili sa sigurnosnim pravilima domene, ili s lokalnim sofisticiranim vatrozidom, ili Bog zna što još. U N-toj iteraciji, administrator mi šalje poveznicu s riječima:
- Pokušajte ponovo pomoću ovih uputa. Tamo je sve poprilično detaljno opisano. Ako ne uspije, pišite autoru ove stranice, možda on može pomoći.
"Ne", kažem, "neće pomoći."
- Zašto?
— Ja sam autor ove stranice... (
Kao rezultat toga, pokrenuli smo ga na Apacheu bez ikakvih problema. IIS nikada nije poražen.
Jedan nivo dublje
Imali smo klijenta - malo proizvodno poduzeće. Imali su server, neku vrstu “klasike” 3 u 1: terminal server + aplikacijski server + server baze podataka. Radili su u nekoj industrijskoj konfiguraciji baziranoj na UPP-u, bilo je oko 15-20 korisnika, a performanse sustava su, načelno, svima odgovarale.
Kako je vrijeme prolazilo, sve je radilo više-manje stabilno. Ali tada je Europa uvela sankcije protiv Rusije, zbog čega su Rusi počeli kupovati uglavnom domaće proizvode, a poslovanje ove tvrtke naglo je krenulo uzbrdo. Broj korisnika se povećao na 50-60 ljudi, otvorena je nova poslovnica, a samim tim i protok dokumenata. A sada se trenutni poslužitelj više nije mogao nositi s naglo povećanim opterećenjem, a 1C je počeo, kako kažu, "usporiti". Tijekom vršnih sati dokumenti su se obrađivali nekoliko minuta, događale su se pogreške u blokiranju, obrasci su se dugo otvarali i cijeli drugi niz povezanih usluga. Lokalni administrator sustava odbacio je sve probleme, rekavši: "Ovo je vaš 1C, shvatit ćete." Više puta smo predlagali provođenje revizije učinkovitosti sustava, ali do same revizije nikada nije došlo. Klijent je jednostavno tražio preporuke kako riješiti probleme.
Pa, sjeo sam i napisao prilično poduže pismo o potrebi razdvajanja uloga terminalskog poslužitelja i aplikacijskog poslužitelja sa DBMS-om (što smo, u principu, već mnogo puta rekli). Pisao sam o DFSS-u na terminalskim poslužiteljima, o dijeljenoj memoriji, dao poveznice na autoritativne izvore i čak predložio neke opcije za opremu. Ovo pismo je stiglo do moćnika u tvrtki, vratilo se u IT odjel s rezolucijama “Implementiraj” i led je uglavnom probijen.
Nakon nekog vremena, administrator mi šalje IP adresu novog poslužitelja i vjerodajnice za prijavu. On kaže da su tamo raspoređene komponente MS SQL i 1C poslužitelja, a potrebno je prenijeti baze podataka, ali za sada samo na DBMS poslužitelj, jer su se pojavili problemi s ključevima 1C.
Ušao sam, istina, radili su svi servisi, server nije bio baš jak, ali ok, mislim da je bolje i to nego ništa. Za sada ću prenijeti baze podataka kako bih nekako rasteretio trenutni server. Završio sam sve transfere u dogovoreno vrijeme, ali situacija se nije promijenila - i dalje isti problemi s izvedbom. Čudno je, naravno, dobro, registrirajmo baze podataka u klasteru 1C pa ćemo vidjeti.
Prošlo je nekoliko dana, a ključevi nisu preneseni. Pitam se u čemu je problem, čini se da je sve jednostavno - izvadite ga iz jednog servera, priključite na drugi, instalirajte driver i gotovo. Administrator odgovara uznemirujući se i govoreći nešto o prosljeđivanju portova, virtualnom poslužitelju i tako dalje.
Hmm... Virtualni poslužitelj? Čini se da virtualizacije nikada nije bilo i nije je bilo... Sjećam se prilično dobro poznatog problema s nemogućnošću prosljeđivanja ključa 1C servera virtualnom stroju na Hyper-V u Windows Server 2008. A evo i ovdje. neke sumnje se počinju stvarati u meni...
Otvaram server manager - Roles - pojavila se nova uloga - Hyper-V. Odem u Hyper-V manager, vidim jedno virtualno računalo, spojim se... I doista... Naš novi poslužitelj baze podataka...
Pa što? Upute nadležnih i moje preporuke su izvršene, uloge su podijeljene. Zadatak se može zatvoriti.
Nakon nekog vremena dogodila se sadašnja kriza, nova podružnica je morala biti zatvorena, opterećenje se smanjilo, a performanse sustava postale su više-manje podnošljive.
Pa, naravno, nisu mogli proslijediti ključ poslužitelja virtualnom stroju. Kao rezultat toga, sve je ostalo kako jest: terminalski poslužitelj + 1C klaster na fizičkom stroju, poslužitelj baze podataka tamo u virtualnom.
I bilo bi lijepo da je ovo nekakav šaraškinov ured. Pa ne. Poznata tvrtka čije proizvode vjerojatno poznajete i vidjeli ste ih u relevantnim odjelima svih Lenta i Auchana.
Raspored odmora za tvrdi disk
Veliki holding s ambicioznim planovima preuzimanja svijeta ponovno je kupio malu tvrtku s ciljem da je uključi u svoju megakorporaciju. U svim odjelima ovog holdinga korisnici rade u svojim bazama podataka, ali s identičnom konfiguracijom. I tako smo započeli mali projekt uključivanja nove jedinice u ovaj sustav.
Prije svega, potrebno je implementirati proizvodne i testne baze podataka. Programer je primio podatke o vezi, prijavljuje se na poslužitelj, vidi instaliran MS SQL, 1C poslužitelj, vidi 2 logička pogona: pogon „C” kapaciteta 250 gigabajta i pogon „D” kapaciteta 1 terabajta. Pa, "C" je sustav, "D" je za podatke, programer logično odlučuje i postavlja sve baze podataka tamo. Čak sam postavio i planove održavanja, uključujući sigurnosnu kopiju, za svaki slučaj (iako nismo odgovorni za to). Istina, sigurnosne kopije su dodane ovdje u "D". U budućnosti je planirano da se rekonfigurira na neki zasebni mrežni resurs.
Projekt je krenuo, konzultanti su proveli obuku za rad u novom sustavu, prebačeni su ostaci, napravljena su manja manja poboljšanja, a korisnici su počeli raditi u novoj informacijskoj bazi.
Sve je išlo dobro do jednog ponedjeljka ujutro kada je otkriveno da nedostaje disk s bazom podataka. Jednostavno nema "D" na serveru i to je to.
Daljnja istraga otkrila je ovo: ovaj "poslužitelj" je zapravo bio radno računalo lokalnog administratora sustava. Istina, još uvijek je imao poslužiteljski OS. Osobni USB pogon ovog administratora bio je priključen na poslužitelj. I tako je administrator otišao na godišnji odmor, ponijevši svoj šaraf sa sobom, s ciljem da u njega ubaci filmove za put.
Hvala Bogu, nije uspio izbrisati datoteke baze podataka i uspio je vratiti produktivnu bazu podataka.
Važno je napomenuti da su svi uglavnom bili zadovoljni performansama sustava koji se nalazi na USB disku. Nitko se nije žalio na bilo kakvu nezadovoljavajuću izvedbu 1C. Tek kasnije je holding započeo mega-projekt prijenosa svih baza podataka na jedno centralizirano mjesto sa super-poslužiteljima, sustavima za pohranu za milijun+ rubalja, sofisticiranim hipervizorima i nepodnošljivim 1C kočnicama u svim podružnicama.
Ali to je sasvim druga priča...
Izvor: www.habr.com