Kõik 1C arendajad suhtlevad ühel või teisel viisil tihedalt IT-teenustega ja otse süsteemiadministraatoritega. Kuid see suhtlus ei kulge alati sujuvalt. Tahaksin teile selle kohta paar naljakat lugu rääkida.
Kiire sidekanal
Enamik meie kliente on suurettevõtted, millel on oma suured IT-osakonnad. Ja teabeandmebaaside varukoopiate eest vastutavad tavaliselt kliendispetsialistid. Kuid on ka suhteliselt väikseid organisatsioone. Eriti nende jaoks on meil teenus, mille kohaselt võtame enda kanda kõik 1C varundamisega seotud küsimused. See on ettevõte, millest me selles loos räägime.
1C-d tuli toetama uus klient ja muuhulgas oli lepingus punkt, et meie vastutame varukoopiate eest, kuigi neil oli oma süsteemiadministraator. Klient-server andmebaas, MS SQL DBMS-ina. Üsna standardne olukord, aga üks nüanss siiski oli: põhibaas oli päris suur, aga igakuine tõus väga väike. See tähendab, et andmebaasis oli palju ajaloolisi andmeid. Seda funktsiooni arvesse võttes koostasin varundushooldusplaanid järgmiselt: iga kuu esimesel laupäeval tehti täielik varukoopia, see oli üsna raske, siis tehti igal õhtul diferentsiaalkoopia - suhteliselt väike koopia ja koopia tehingulogi iga tund. Lisaks ei kopeeritud täis- ja diferentseeritud koopiaid ainult võrguressurssi, vaid laaditi ka täiendavalt üles meie FTP-serverisse. See on selle teenuse osutamisel kohustuslik nõue.
Kõik see oli edukalt konfigureeritud, kasutusele võetud ja üldiselt töötas tõrgeteta.
Kuid paar kuud hiljem vahetus selles organisatsioonis süsteemiadministraator. Uus süsteemiadministraator asus ettevõtte IT-taristut järk-järgult ümber ehitama vastavalt kaasaegsetele trendidele. Eelkõige ilmus virtualiseerimine, kettariiulid, juurdepääs blokeeriti kõikjal ja kõiges jne, mis üldiselt ei saa muidugi muud üle kui rõõmustada. Kuid tema jaoks ei läinud asjad alati libedalt, 1C toimimisega tekkis sageli probleeme, mis põhjustas meie toel mõningaid lahkarvamusi ja arusaamatusi. Samuti tuleb märkida, et meie suhted temaga olid üldiselt üsna külmad ja mõnevõrra pingelised, mis probleemide ilmnemisel ainult suurendas pinget.
Kuid ühel hommikul selgus, et selle kliendi server polnud saadaval. Helistasin süsteemiadministraatorile, et uurida, mis juhtus, ja sain vastuseks umbes sellise: "Meie server jooksis kokku, töötame selle kallal, teie jaoks pole aega." Hea, et nad töötavad. See tähendab, et olukord on kontrolli all. Peale lõunat helistan uuesti ja ärrituse asemel tunnen juba adminni hääles väsimust ja apaatsust. Püüan aru saada, mis juhtus ja kas saame midagi aidata? Vestluse tulemusena selgus järgmine:
Ta viis serveri äsja kokkupandud reidiga uude salvestussüsteemi. Kuid midagi läks valesti ja paar päeva hiljem varises see haarang turvaliselt kokku. Kas kontroller põles läbi või juhtus midagi ketastega, ma täpselt ei mäleta, kuid kogu teave läks pöördumatult kaduma. Ja peaasi, et samale kettamassiivile sattus erinevate migratsioonide käigus ka võrguressurss koos varukoopiatega. See tähendab, et nii produktiivne andmebaas ise kui ka kõik selle varukoopiad läksid kaduma. Ja pole selge, mida nüüd teha.
Rahune maha, ma ütlen. Meil on teie igaõhtune varu. Vastuseks oli vaikus, mille läbi sain aru, et päästsin just mehe elu. Hakkame arutama, kuidas seda koopiat uude, äsja juurutatud serverisse üle kanda. Kuid ka siin tekkis probleem.
Mäletate, kui ütlesin, et täielik varukoopia oli üsna suur? Ega asjata tegin seda kord kuus laupäeviti. Fakt on see, et ettevõte oli väike tehas, mis asus linnast kaugel ja nende internet oli väga so-so. Esmaspäeva hommikuks, see tähendab nädalavahetusel, jõudis see koopia vaevalt meie FTP-serverisse üles laadida. Kuid ei saanud kuidagi oodata päeva või paar, et see vastassuunas laadiks. Peale mitut ebaõnnestunud faili teisaldamise katset võttis administraator kõvaketta otse uuest serverist välja, leidis kuskilt auto koos juhiga ja tormas kiiresti meie kontorisse, õnneks oleme ikka samas linnas.
Kui nad meie serveriruumis seisid ja failide kopeerimist ootasid, kohtusime esimest korda nii-öelda “isiklikult”, jõime tassi kohvi ja rääkisime mitteametlikus keskkonnas. Elasin tema leinale kaasa ja saatsin ta täie varukoopiaga tagasi, taastades kiiruga ettevõtte seisma jäänud tööd.
Seejärel lahendati kõik meie pöördumised IT-osakonnale väga kiiresti ja enam erimeelsusi ei tekkinud.
Võtke ühendust oma süsteemiadministraatoriga
Kunagi, väga pikka aega, ei saanud ma ühe kliendi jaoks IIS-i kaudu veebijuurdepääsu jaoks 1C-d avaldada. See tundus tavaline ülesanne, kuid kõike ei saanud kuidagi käima saada. Kohalikud süsteemiadministraatorid osalesid ja proovisid erinevaid sätteid ja konfiguratsioonifaile. 1C veebis ei tahtnud tavaliselt kuidagi töötada. Midagi oli valesti, kas domeeni turvapoliitikaga või kohaliku keeruka tulemüüriga või jumal teab milles veel. N-ndal iteratsioonil saadab administraator mulle lingi sõnadega:
- Proovige uuesti, järgides neid juhiseid. Seal on kõik üsna üksikasjalikult kirjeldatud. Kui see ei tööta, kirjutage selle saidi autorile, võib-olla saab ta aidata.
"Ei," ütlen ma, "see ei aita."
- Miks?
— Olen selle saidi autor... (
Selle tulemusena käivitasime selle Apache'is ilma probleemideta. IIS ei saanud kunagi lüüa.
Üks tase sügavam
Meil oli klient – väike tootmisettevõte. Neil oli server, omamoodi "klassikaline" kolm ühes: terminaliserver + rakendusserver + andmebaasiserver. Nad töötasid mingis UPP-l põhinevas tööstusharuspetsiifilises konfiguratsioonis, kasutajaid oli umbes 3-1 ja süsteemi jõudlus sobis põhimõtteliselt kõigile.
Aja möödudes töötas kõik enam-vähem stabiilselt. Kuid siis kehtestas Euroopa Venemaa vastu sanktsioonid, mille tulemusena hakkasid venelased ostma peamiselt kodumaist toodangut ja selle ettevõtte äri läks järsult ülesmäge. Kasutajate arv kasvas 50-60 inimeseni, avati uus esindus ja vastavalt suurenes ka dokumendivoog. Ja nüüd ei saanud praegune server enam järsult suurenenud koormusega hakkama ja 1C hakkas, nagu öeldakse, “aeglustuma”. Tipptundidel töödeldi dokumente mitu minutit, ilmnes blokeerimisvigu, vormide avamine võttis kaua aega ja kogu muu kimp seotud teenuseid. Kohalik süsteemiadministraator kõrvaldas kõik probleemid, öeldes: "See on teie 1C, saate selle välja mõelda." Oleme korduvalt teinud ettepaneku viia läbi süsteemi tulemusaudit, kuid tegelik audit ei teostunud. Klient küsis lihtsalt soovitusi probleemide lahendamiseks.
Noh, ma istusin maha ja kirjutasin üsna pika kirja vajadusest eraldada terminaliserveri ja rakendusserveri rollid DBMS-iga (mida oleme põhimõtteliselt juba mitu korda varem öelnud). Kirjutasin DFSS-ist terminaliserverites, jagatud mälust, andsin linke autoriteetsetele allikatele ja isegi soovitasin mõningaid seadmete valikuid. See kiri jõudis ettevõttes võimukandjateni, läks tagasi IT-osakonda resolutsioonidega “Rakendada” ja jää oli üldiselt murtud.
Mõne aja pärast saadab administraator mulle uue serveri IP-aadressi ja sisselogimismandaadid. Ta ütleb, et seal on juurutatud MS SQL ja 1C serverikomponendid ning andmebaasid tuleb üle kanda, kuid praegu ainult DBMS-i serverisse, kuna 1C võtmetega on tekkinud probleeme.
Tulin sisse, tõepoolest, kõik teenused töötasid, server polnud kuigi võimas, aga ok, ma arvan, et see on parem kui mitte midagi. Annan praegu andmebaasid üle, et praegust serverit kuidagi leevendada. Tegin kõik ülekanded kokkulepitud ajal valmis, aga olukord ei muutunud - ikka samad jõudlusprobleemid. See on muidugi kummaline, noh, registreerime andmebaasid 1C klastris ja näeme.
Möödub mitu päeva, võtmeid pole üle antud. Huvitav, milles probleem, kõik tundub olevat lihtne – võta see ühest serverist välja, ühenda teisega, installeeri draiver ja ongi valmis. Administraator vastab pabistades ja ütleb midagi pordi edastamise, virtuaalserveri jms kohta.
Hmm... Virtuaalne server? Tundub, et virtualiseerimist pole kunagi olnud ja pole ka kunagi olnud... Mulle meenub üsna tuntud probleem seoses 1C-serverivõtme võimatusega edastada Windows Server 2008-s Hyper-V virtuaalmasinasse. Ja siin minus hakkavad tekkima mingid kahtlused...
Avan serverihalduri - Rollid - ilmus uus roll - Hyper-V. Lähen Hyper-V haldurisse, vaatan ühte virtuaalmasinat, loon ühenduse... Ja tõepoolest... Meie uus andmebaasiserver...
Mis siis? Ametiasutuste juhised ja minu soovitused on täidetud, rollid on eraldatud. Ülesande saab sulgeda.
Mõne aja pärast saabus praegune kriis, uus filiaal tuli sulgeda, koormus vähenes ja süsteemi jõudlus muutus enam-vähem talutavaks.
Muidugi ei saanud nad serveri võtit virtuaalmasinasse edastada. Selle tulemusena jäi kõik nii nagu on: terminaliserver + 1C klaster füüsilises masinas, andmebaasiserver seal virtuaalses.
Ja oleks tore, kui see oleks mingi Šaraškini kontor. Nii et ei. Tuntud ettevõte, mille tooteid te ilmselt teate ja olete näinud kõigi Lentade ja Auchanite vastavates osakondades.
Kõvaketta puhkuse ajakava
Ambitsioonikate maailma vallutamise plaanidega suur valdusfirma ostis taas väikese ettevõtte eesmärgiga kaasata see oma megakorporatsiooni. Selle ettevõtte kõigis osakondades töötavad kasutajad oma andmebaasides, kuid identse konfiguratsiooniga. Ja nii alustasime väikese projektiga, et lisada sellesse süsteemi uus üksus.
Kõigepealt on vaja juurutada tootmis- ja testiandmebaasid. Arendaja sai ühendusandmed, logib sisse serverisse, näeb installitud MS SQL-i, 1C-serverit, näeb 2 loogilist draivi: 250 gigabaidise mahuga draiv “C” ja 1 terabaidine draiv “D”. Noh, “C” on süsteem, “D” on andmete jaoks, arendaja otsustab loogiliselt ja juurutab kõik seal olevad andmebaasid. Panin igaks juhuks paika isegi hooldusplaanid, sh varundamise (kuigi me selle eest ei vastuta). Tõsi, varukoopiad lisati siia “D”-le. Tulevikus oli plaanis see ümber seadistada mõneks eraldiseisvaks võrguressursiks.
Projekt algas, konsultandid korraldasid uues süsteemis töötamise koolituse, ülejäägid viidi üle, tehti väiksemaid parandusi ning kasutajad asusid tööle uues infobaasis.
Kõik läks hästi, kuni ühel esmaspäeva hommikul avastati, et andmebaasi ketas on puudu. Serveris pole lihtsalt D-tähte ja kõik.
Edasine uurimine paljastas selle: see "server" oli tegelikult kohaliku süsteemiadministraatori tööarvuti. Tõsi, sellel oli ikkagi serveri OS. Selle administraatori isiklik USB-draiv ühendati serveriga. Ja nii läks administraator puhkusele, võttes kaasa oma kruvi, eesmärgiga pumbata sellesse reisi jaoks filme.
Jumal tänatud, et tal ei õnnestunud andmebaasifaile kustutada ja õnnestus produktiivne andmebaas taastada.
Tähelepanuväärne on see, et kõik jäid USB-draivil asuva süsteemi jõudlusega üldiselt rahule. Keegi ei kurtnud 1C ebarahuldava jõudluse üle. Alles hiljem alustas valdus megaprojekti, mille eesmärk oli viia kõik teabeandmebaasid ühte tsentraliseeritud saidile koos superserveritega, üle miljoni rubla maksvate salvestussüsteemide, keerukate hüperviisorite ja kõigis harudes väljakannatamatud 1C-piduritega.
Aga see on hoopis teine lugu...
Allikas: www.habr.com