Alle 1C-ontwikkelaars is op een of ander manier in noue interaksie met IT-dienste en direk met stelseladministrateurs. Maar hierdie interaksie verloop nie altyd vlot nie. Ek wil graag vir jou 'n paar snaakse stories hieroor vertel.
Hoëspoed kommunikasie kanaal
Die meeste van ons kliënte is groot hoewes met hul eie groot IT-afdelings. En kliëntspesialiste is gewoonlik verantwoordelik vir rugsteunkopieë van inligtingdatabasisse. Maar daar is ook relatief klein organisasies. Veral vir hulle het ons 'n diens waarvolgens ons alle kwessies wat verband hou met rugsteun van alles 1C op onsself neem. Dit is die maatskappy waaroor ons in hierdie storie sal praat.
'n Nuwe kliënt het 1C kom ondersteun en die kontrak het onder meer 'n klousule ingesluit dat ons verantwoordelik is vir rugsteun, hoewel hulle hul eie stelseladministrateur op personeel gehad het. Kliënt-bediener databasis, MS SQL as 'n DBBS. 'n Redelik standaard situasie, maar daar was nog een nuanse: die hoofbasis was redelik groot, maar die maandelikse verhoging was baie klein. Dit wil sê, die databasis het baie historiese data bevat. Met hierdie kenmerk in ag geneem, het ek rugsteun-instandhoudingsplanne soos volg opgestel: op die eerste Saterdag van elke maand is 'n volledige rugsteun gemaak, dit was redelik swaar, dan is 'n differensiële kopie elke aand gemaak - 'n relatief klein volume, en 'n kopie van die transaksielogboek elke uur. Boonop is volledige en differensiële kopieë nie net na 'n netwerkhulpbron gekopieer nie, maar ook bykomend na ons FTP-bediener opgelaai. Dit is 'n verpligte vereiste wanneer hierdie diens verskaf word.
Dit alles is suksesvol gekonfigureer, in werking gestel en het oor die algemeen sonder mislukkings gewerk.
Maar 'n paar maande later het die stelseladministrateur in hierdie organisasie verander. Die nuwe stelseladministrateur het begin om die maatskappy se IT-infrastruktuur geleidelik te herbou in ooreenstemming met moderne neigings. Veral virtualisasie het verskyn, skyfrakke, toegang is oral geblokkeer en alles, ens., wat in die algemene geval natuurlik nie anders kan as om te jubel nie. Maar dinge het nie altyd glad vir hom gegaan nie; daar was dikwels probleme met die prestasie van 1C, wat 'n paar meningsverskille en misverstande met ons ondersteuning veroorsaak het. Daar moet ook op gelet word dat ons verhouding met hom oor die algemeen redelik koud en ietwat gespanne was, wat net die mate van spanning verhoog het in die geval van enige probleme.
Maar een oggend het dit geblyk dat hierdie kliënt se bediener nie beskikbaar was nie. Ek het die stelseladministrateur gebel om uit te vind wat gebeur het en het as 'n antwoord iets ontvang soos "Ons bediener het omgeval, ons werk daaraan, nie aan jou nie." Wel, dit is goed dat hulle werk. Dit beteken die situasie is onder beheer. Na middagete bel ek weer terug, en in plaas van irritasie kan ek reeds moegheid en apatie in die admin se stem voel. Ek probeer uitvind wat gebeur het en is daar enigiets wat ons kan doen om te help? As gevolg van die gesprek het die volgende na vore gekom:
Hy het die bediener na 'n nuwe stoorstelsel geskuif met 'n nuut saamgestelde klopjag. Maar iets het verkeerd geloop en 'n paar dae later het hierdie klopjag veilig ineengestort. Of die kontroleerder uitgebrand het of iets met die skywe gebeur het, ek onthou nie presies nie, maar al die inligting het onherstelbaar verlore gegaan. En die belangrikste ding was dat die netwerkhulpbron met rugsteun ook tydens verskeie migrasies op dieselfde skyfskikking beland het. Dit wil sê, beide die produktiewe databasis self en al sy rugsteunkopieë het verlore gegaan. En dit is onduidelik wat om nou te doen.
Kalmeer, sê ek. Ons het jou nagtelike rugsteun. In reaksie hierop was daar stilte, waardeur ek besef het dat ek pas 'n man se lewe gered het. Ons begin bespreek hoe om hierdie kopie na 'n nuwe, nuut ontplooide bediener oor te dra. Maar ook hier het 'n probleem ontstaan.
Onthou jy toe ek gesê het dat die volledige rugsteun redelik groot was? Dit was nie verniet dat ek dit een keer per maand op Saterdae gedoen het nie. Die feit is dat die maatskappy 'n klein aanleg was, wat ver buite die stad geleë was en hul internet was baie so-so. Teen Maandagoggend, dit wil sê oor die naweek, kon hierdie kopie skaars na ons FTP-bediener opgelaai word. Maar daar was geen manier om 'n dag of twee te wag vir dit om in die teenoorgestelde rigting te laai nie. Na verskeie onsuksesvolle pogings om die lêer oor te dra, het die administrateur die hardeskyf direk vanaf die nuwe bediener uitgehaal, iewers 'n motor met 'n bestuurder gekry en vinnig na ons kantoor gehaas, gelukkig is ons nog in dieselfde stad.
Terwyl hulle in ons bedienerkamer gestaan en wag het dat die lêers gekopieer word, het ons vir die eerste keer so te sê “persoonlik” ontmoet, 'n koppie koffie gedrink en in 'n informele omgewing gesels. Ek het simpatie gehad met sy hartseer en hom teruggestuur met 'n vol skroef van rugsteun, wat inderhaas die gestopte werk van die maatskappy herstel het.
Daarna is al ons versoeke aan die IT-afdeling baie vinnig opgelos en geen meningsverskille het meer ontstaan nie.
Kontak jou stelseladministrateur
Een keer, vir 'n baie lang tyd, kon ek nie 1C vir webtoegang via IIS vir een kliënt publiseer nie. Dit het na 'n gewone taak gelyk, maar daar was geen manier om alles aan die gang te kry nie. Plaaslike stelseladministrateurs het betrokke geraak en verskillende instellings en konfigurasielêers probeer. 1C op die web wou normaalweg nie op enige manier werk nie. Iets was verkeerd, hetsy met domeinsekuriteitsbeleide, of met die plaaslike gesofistikeerde firewall, of God weet wat nog. Op die Nde iterasie stuur die admin vir my 'n skakel met die woorde:
- Probeer weer deur hierdie instruksies te gebruik. Alles word daar in baie besonderhede beskryf. As dit nie werk nie, skryf aan die skrywer van hierdie webwerf, miskien kan hy help.
“Nee,” sê ek, “dit sal nie help nie.”
- Hoekom?
— Ek is die skrywer van hierdie webwerf... (
As gevolg hiervan het ons dit sonder enige probleme op Apache bekendgestel. IIS is nooit verslaan nie.
Een vlak dieper
Ons het 'n kliënt gehad - 'n klein vervaardigingsonderneming. Hulle het 'n bediener gehad, 'n soort "klassieke" 3 in 1: terminale bediener + toepassingsbediener + databasisbediener. Hulle het gewerk in een of ander bedryfspesifieke konfigurasie gebaseer op UPP, daar was ongeveer 15-20 gebruikers, en die werkverrigting van die stelsel het in beginsel almal gepas.
Met verloop van tyd het alles min of meer stabiel gewerk. Maar toe het Europa sanksies teen Rusland ingestel, as gevolg waarvan Russe hoofsaaklik plaaslik vervaardigde produkte begin koop het, en sake vir hierdie maatskappy het skerp opdraand gegaan. Die aantal gebruikers het tot 50-60 mense toegeneem, 'n nuwe tak is geopen, en dokumentvloei het dienooreenkomstig toegeneem. En nou kon die huidige bediener nie meer die skerp verhoogde las hanteer nie, en 1C het, soos hulle sê, begin "vertraag". Gedurende spitstye is dokumente vir etlike minute verwerk, blokkeerfoute het voorgekom, vorms het lank geneem om oop te maak, en die hele ander boeket van verwante dienste. Die plaaslike stelseladministrateur het al die probleme afgeskaf en gesê: "Dit is jou 1C, jy sal dit uitvind." Ons het herhaaldelik voorgestel om 'n prestasie-oudit van die stelsel uit te voer, maar dit het nooit tot die oudit self gekom nie. Die kliënt het bloot vir aanbevelings gevra oor hoe om probleme op te los.
Wel, ek het gaan sit en 'n taamlike lang brief geskryf oor die behoefte om die rolle van die terminale bediener en die toepassingsbediener met die DBMS te skei (wat ons in beginsel al baie keer voorheen gesê het). Ek het geskryf oor DFSS op terminale bedieners, oor gedeelde geheue, skakels na gesaghebbende bronne verskaf, en selfs 'n paar opsies vir toerusting voorgestel. Hierdie brief het die maghebbers in die maatskappy bereik, teruggegaan na die IT-afdeling met die resolusies “Implementeer” en die ys was oor die algemeen gebreek.
Na 'n rukkie stuur die admin vir my die IP-adres van die nuwe bediener en aanmeldbewyse. Hy sê dat MS SQL- en 1C-bedienerkomponente daar ontplooi is, en die databasisse moet oorgedra word, maar vir eers net na die DBMS-bediener, aangesien daar probleme met die 1C-sleutels ontstaan het.
Ek het ingekom, inderdaad, al die dienste was aan die gang, die bediener was nie baie kragtig nie, maar ok, ek dink dit is beter as niks. Ek sal die databasisse vir eers oordra om die huidige bediener op een of ander manier te verlig. Ek het al die oordragte op die ooreengekome tyd voltooi, maar die situasie het nie verander nie – steeds dieselfde prestasieprobleme. Dit is natuurlik vreemd, wel, kom ons registreer die databasisse in die 1C-kluster en ons sal sien.
'n Paar dae gaan verby, die sleutels is nie oorgedra nie. Ek wonder wat die probleem is, alles blyk eenvoudig te wees - haal dit uit een bediener, prop dit in 'n ander, installeer die drywer en jy is klaar. Die admin reageer deur te raas en iets te sê oor poortaanstuur, 'n virtuele bediener, ensovoorts.
Hmm... Virtuele bediener? Dit blyk dat daar nog nooit enige virtualisering was nie en daar was nog nooit enige... Ek onthou 'n redelik bekende probleem met die onmoontlikheid om 'n 1C-bedienersleutel na 'n virtuele masjien op Hyper-V in Windows Server 2008 aan te stuur. En hier sommige vermoedens begin by my vorm...
Ek maak die bedienerbestuurder oop - Rolle - 'n nuwe rol het verskyn - Hyper-V. Ek gaan na die Hyper-V-bestuurder, sien een virtuele masjien, verbind... En sowaar... Ons nuwe databasisbediener...
So wat? Die instruksies van die owerhede en my aanbevelings is uitgevoer, die rolle is geskei. Die taak kan gesluit word.
Na 'n ruk het die nou krisis gebeur, die nuwe tak moes gesluit word, die las het afgeneem en die stelsel se werkverrigting het min of meer draaglik geword.
Wel, hulle kon natuurlik nie die bedienersleutel na die virtuele masjien aanstuur nie. As gevolg hiervan is alles net so gelaat: terminale bediener + 1C-groepering op 'n fisiese masjien, databasisbediener daar in 'n virtuele een.
En dit sal lekker wees as dit 'n soort van Sharashkin se kantoor was. Dus nee. 'n Bekende maatskappy wie se produkte jy waarskynlik in die betrokke afdelings van alle Lentas en Auchans ken en gesien het.
Hardeskyf vakansie skedule
’n Groot beheermaatskappy met ambisieuse planne om die wêreld oor te neem, het weer ’n klein maatskappy gekoop met die doel om dit by sy megakorporasie in te sluit. In alle afdelings van hierdie hoewe werk gebruikers in hul eie databasisse, maar met 'n identiese konfigurasie. En so het ons 'n klein projek begin om 'n nuwe eenheid by hierdie stelsel in te sluit.
Eerstens is dit nodig om produksie- en toetsdatabasisse te ontplooi. Die ontwikkelaar het die verbindingsdata ontvang, aanmeld by die bediener, sien MS SQL geïnstalleer, 1C-bediener, sien 2 logiese dryf: dryf “C” met 'n kapasiteit van 250 gigagrepe en stasie "D" met 'n kapasiteit van 1 teragreep. Wel, "C" is die stelsel, "D" is vir data, die ontwikkelaar besluit logies en ontplooi al die databasisse daar. Ek het selfs instandhoudingsplanne opgestel, insluitend rugsteun, net vir ingeval (al is ons nie hiervoor verantwoordelik nie). True, rugsteun is hier by "D" gevoeg. In die toekoms is daar beplan om dit na een of ander afsonderlike netwerkhulpbron te herkonfigureer.
Die projek het begin, konsultante het opleiding gegee oor hoe om in die nuwe stelsel te werk, oorskiet is oorgedra, 'n paar klein klein verbeterings is aangebring en gebruikers het in die nuwe inligtingsbasis begin werk.
Alles het goed gegaan tot een Maandagoggend toe ontdek is dat die databasisskyf vermis is. Daar is eenvoudig geen "D" op die bediener nie en dit is dit.
Verdere ondersoek het dit aan die lig gebring: hierdie "bediener" was in werklikheid die werkrekenaar van 'n plaaslike stelseladministrateur. Dit is waar, dit het steeds 'n bediener-bedryfstelsel gehad. Hierdie administrateur se persoonlike USB-stasie is by die bediener ingeprop. En so het die administrateur met vakansie gegaan en sy skroef saamgeneem, met die doel om flieks daarin te pomp vir die reis.
Goddank, hy het nie daarin geslaag om die databasislêers uit te vee nie en het daarin geslaag om die produktiewe databasis te herstel.
Dit is opmerklik dat almal oor die algemeen tevrede was met die werkverrigting van die stelsel wat op 'n USB-stasie geleë is. Niemand het gekla oor enige onbevredigende prestasie van 1C nie. Dit was eers later dat die hoewe 'n megaprojek begin het om alle inligtingdatabasisse na 'n enkele gesentraliseerde webwerf met superbedieners, stoorstelsels vir 'n miljoen+ roebels, gesofistikeerde hipervisers en ondraaglike 1C-remme in alle takke oor te dra.
Maar dis 'n heel ander storie...
Bron: will.com