Alle 1C-ûntwikkelders hawwe op ien of oare manier nau ynteraksje mei IT-tsjinsten en direkt mei systeembehearders. Mar dizze ynteraksje giet net altyd soepel. Ik soe hjir graach in pear grappige ferhalen oer fertelle.
High-speed kommunikaasje kanaal
De measte fan ús kliïnten binne grutte holdings mei har eigen grutte IT-ôfdielingen. En kliïntspesjalisten binne normaal ferantwurdlik foar reservekopyen fan ynformaasjedatabases. Mar der binne ek relatyf lytse organisaasjes. Spesjaal foar harren, wy hawwe in tsjinst neffens dêr't wy nimme op ússels alle saken yn ferbân mei reservekopy fan alles 1C. Dit is it bedriuw dat wy sille prate oer yn dit ferhaal.
In nije klant kaam om 1C te stypjen en, ûnder oare, it kontrakt befette in klausule dat wy ferantwurdlik wiene foar backups, hoewol se har eigen systeembehearder op personiel hiene. Client-tsjinner databank, MS SQL as DBMS. In frij standert situaasje, mar der wie noch ien nuânse: de haadbasis wie frij grut, mar de moanlikse ferheging wie tige lyts. Dat is, de databank befette in protte histoaryske gegevens. Mei dizze funksje yn rekken brocht, set ik reserveûnderhâldsplannen as folget op: op 'e earste sneon fan elke moanne waard in folsleine reservekopy makke, it wie frij swier, dan waard elke nacht in differinsjaal kopy makke - in relatyf lyts folume, en in kopy fan de transaksje log elk oere. Boppedat waarden folsleine en differinsjale kopyen net allinich kopiearre nei in netwurkboarne, mar ek opladen nei ús FTP-tsjinner. Dit is in ferplichte eask by it leverjen fan dizze tsjinst.
Dit alles waard mei súkses konfigurearre, yn gebrûk naam en wurke yn 't algemien sûnder mislearrings.
Mar in pear moanne letter feroare de systeembehearder yn dizze organisaasje. De nije systeembehearder begon stadichoan de IT-ynfrastruktuer fan it bedriuw op te bouwen yn oerienstimming mei moderne trends. Yn it bysûnder ferskynde virtualisaasje, skiifplanken, tagong waard oeral blokkearre en alles, ensfh., dy't yn it algemien gefal, fansels, net oars kinne as bliid wêze. Mar dingen gongen net altyd soepel foar him; d'r wiene faak problemen mei de prestaasjes fan 1C, dy't feroarsake wat ûnienigens en misferstannen mei ús stipe. Dêrby moat opmurken wurde dat ús relaasje mei him wie oer it algemien frij kâld en wat spand, dy't allinnich ferhege de mjitte fan spanning yn it gefal fan eventuele problemen.
Mar op in moarn die bliken dat de tsjinner fan dizze klant net beskikber wie. Ik belle de systeembehearder om út te finen wat der bard is en krige as antwurd iets as "Us server is ferûngelokke, wy wurkje der oan, net oan jo." No, it is goed dat se wurkje. Dit betsjut dat de situaasje ûnder kontrôle is. Nei it middeis belje ik wer werom, en ynstee fan yrritaasje kin ik al wurgens en apathy fiele yn de stim fan de admin. Ik besykje út te finen wat der bard is en is d'r wat dat wy kinne dwaan om te helpen? As gefolch fan it petear kaam it folgjende nei foaren:
Hy ferhuze de tsjinner nei in nij opslachsysteem mei in nij gearstalde oerfal. Mar der gie der wat mis en in pear dagen letter stoarte dizze oerfal feilich yn. Oft de controller baarnde út of der bard wat mei de skiven, Ik wit net ûnthâlde krekt, mar alle ynformaasje wie irretrievably ferlern. En it wichtichste ding wie dat de netwurkboarne mei backups ek by ferskate migraasjes op deselde skiif-array kaam. Dat is, sawol de produktive databank sels as al syn reservekopyen binne ferlern gien. En it is ûndúdlik wat no te dwaan.
Rêstich, sis ik. Wy hawwe jo nachtlike reservekopy. As antwurd wie der stil, wêrby't ik besefte dat ik krekt it libben fan in man rêden hie. Wy begjinne te besprekken hoe't jo dizze kopy kinne oerdrage nei in nije, nij ynset server. Mar ek hjir ûntstie in probleem.
Unthâld doe't ik sei dat de folsleine reservekopy wie frij grut? It wie net foar neat dat ik it ien kear yn 'e moanne op sneon dien. It feit is dat it bedriuw wie in lytse plant, dat wie leit fier bûten de stêd en harren ynternet wie hiel sa-so. Tsjin moandeitemoarn, dat wol sizze, yn it wykein, koe dit eksimplaar amper opladen wurde op ús FTP-tsjinner. Mar d'r wie gjin manier om in dei as twa te wachtsjen foar it laden yn 'e tsjinoerstelde rjochting. Nei ferskate mislearre besykjen om it bestân oer te setten, helle de behearder de hurde skiif direkt fan 'e nije tsjinner, fûn earne in auto mei in bestjoerder en rûn gau nei ús kantoar, gelokkich binne wy noch yn deselde stêd.
Wylst se yn ús serverkeamer stiene te wachtsjen op it kopiearjen fan de bestannen, troffen wy foar it earst, om sa te sizzen, "persoanlik", in bakje kofje en praatten yn in ynformele setting. Ik sympatisearre mei syn fertriet en stjoerde him werom mei in folsleine skroef fan backups, hastich it stoppe wurk fan it bedriuw te herstellen.
Dêrnei waarden al ús oanfragen oan de IT-ôfdieling tige fluch oplost en ûntstiene der gjin ûnienigens mear.
Nim kontakt op mei jo systeembehearder
Ienris, foar in heul lange tiid, koe ik 1C net publisearje foar webtagong fia IIS foar ien kliïnt. It like in gewoane taak, mar der wie gjin manier om alles rinnend te krijen. Lokale systeembehearders wiene belutsen en besochten ferskate ynstellings en konfiguraasjebestannen. 1C op it web woe normaal net op ien of oare manier wurkje. Der wie wat mis, itsij mei domeinfeiligensbelied, of mei de pleatslike ferfine firewall, of God wit wat oars. Op de Nde iteraasje stjoert de admin my in keppeling mei de wurden:
- Besykje nochris mei dizze ynstruksjes. Alles wurdt dêr yn hiel detail beskreaun. As it net wurket, skriuw dan nei de skriuwer fan dizze side, miskien kin hy helpe.
"Nee," sis ik, "it sil net helpe."
- Wêrom?
- Ik bin de skriuwer fan dizze side... (
As gefolch hawwe wy it sûnder problemen op Apache lansearre. IIS waard nea ferslein.
Ien nivo djipper
Wy hiene in klant - in lyts produksjebedriuw. Se hiene in tsjinner, in soarte fan "klassike" 3 yn 1: terminal tsjinner + applikaasje tsjinner + databank tsjinner. Se wurken yn guon yndustry-spesifike konfiguraasje basearre op UPP, d'r wiene sa'n 15-20 brûkers, en de prestaasjes fan it systeem pasten yn prinsipe elkenien.
Nei ferrin fan tiid wurke alles min of mear stabyl. Mar doe lei Europa sanksjes tsjin Ruslân, wêrtroch't de Russen foaral ynlânske produkten begûnen te keapjen, en it bedriuw foar dit bedriuw gie hurd omheech. It oantal brûkers tanommen nei 50-60 minsken, in nije tûke waard iepene, en dokumint stream tanommen neffens. En no koe de hjoeddeiske tsjinner net mear omgean mei de sterk ferhege lading, en 1C begon, sa't se sizze, "fertrage". Tidens peak oeren, dokuminten waarden ferwurke foar ferskate minuten, blokkearjen flaters barde, formulieren naam in lange tiid om te iepenjen, en de hiele oare bouquet fan besibbe tsjinsten. De lokale systeembehearder hat alle problemen fuorthelle en sei: "Dit is jo 1C, jo sille it útfine." Wy hawwe ferskate kearen foarsteld in útfiering kontrôle fan it systeem, mar it kaam nea ta de kontrôle sels. De kliïnt frege gewoan om oanbefellings oer hoe't problemen kinne reparearje.
No, ik siet en skreau in frij lange brief oer de needsaak om de rollen fan 'e terminaltsjinner en de applikaasjetsjinner te skieden mei de DBMS (wat wy yn prinsipe al in protte kearen earder sein hawwe). Ik skreau oer DFSS op terminalservers, oer Shared Memory, levere keppelings nei gesachhawwende boarnen, en suggerearre sels guon opsjes foar apparatuer. Dizze brief berikte de machthawwers yn it bedriuw, gie werom nei de IT-ôfdieling mei de resolúsjes "Ynfiere" en it iis wie oer it algemien brutsen.
Nei in skoftke stjoert de admin my it IP-adres fan 'e nije server en ynloggegevens. Hy seit dat MS SQL en 1C tsjinner ûnderdielen wurde ynset dêr, en de databases moatte wurde oerdroegen, mar foar no allinnich nei de DBMS tsjinner, sûnt guon problemen binne ûntstien mei de 1C kaaien.
Ik kaam yn, yndie, alle tsjinsten rinne, de tsjinner wie net hiel machtich, mar ok, ik tink dat it is better as neat. Ik sil de databases foar no oerdrage om de hjoeddeistige tsjinner op ien of oare manier te ûntlêsten. Ik foltôge alle oerstappen op 'e ôfsprutsen tiid, mar de situaasje feroare net - noch altyd deselde prestaasjesproblemen. It is nuver, fansels, goed, litte wy de databases registrearje yn it 1C-kluster en wy sille sjen.
Ferskate dagen geane foarby, de kaaien binne net oerdroegen. Ik freegje my ôf wat it probleem is, alles liket ienfâldich te wêzen - nim it út ien server, plug it yn in oare, ynstallearje de bestjoerder en jo binne klear. De admin reagearret troch te droegjen en wat te sizzen oer poarte trochstjoere, in firtuele server, ensfh.
Hmm... Firtuele tsjinner? It liket derop dat d'r noait gjin virtualisaasje west hat en d'r noch noait west hawwe ... Ik herinner my in frij bekend probleem mei de ûnmooglikheid om in 1C-tsjinnerkaai troch te stjoeren nei in firtuele masine op Hyper-V yn Windows Server 2008. En hjir guon fermoedens begjinne by my te foarmjen ...
Ik iepenje de serverbehearder - Rollen - in nije rol is ferskynd - Hyper-V. Ik gean nei de Hyper-V-manager, sjoch ien firtuele masine, ferbine ... En yndie ... Us nije databanktsjinner ...
No en? De ynstruksjes fan 'e autoriteiten en myn oanbefellings binne útfierd, de rollen binne skieden. De taak kin sluten wurde.
Nei ferrin fan tiid barde de no krisis, de nije filiaal moast sluten wurde, de lading fermindere, en de systeemprestaasjes waarden min of mear tolerabel.
No, fansels, se koenen de serverkaai net trochstjoere nei de firtuele masine. As gefolch, alles bleau sa't is: terminal tsjinner + 1C kluster op in fysike masine, databank tsjinner dêr yn in firtuele.
En it soe moai wêze as dit in soarte fan sharashkin-kantoar wie. Dus nee. In bekend bedriuw waans produkten jo wierskynlik kenne en hawwe sjoen yn 'e oanbelangjende ôfdielingen fan alle Lentas en Auchans.
Hurde skiif fakânsje skema
In grut holdingbedriuw mei ambisjeuze plannen om de wrâld oer te nimmen hat op 'e nij in lyts bedriuw kocht mei as doel it op te nimmen yn har megakorporaasje. Yn alle ôfdielingen fan dizze holding wurkje brûkers yn har eigen databases, mar mei in identike konfiguraasje. En sa begûnen wy in lyts projekt om in nije ienheid yn dit systeem op te nimmen.
As earste is it nedich om produksje- en testdatabases yn te setten. De ûntwikkelder ûntfong de ferbiningsgegevens, logt yn op 'e tsjinner, sjocht MS SQL ynstalleare, 1C-tsjinner, sjocht 2 logyske driuwfearren: drive "C" mei in kapasiteit fan 250 gigabyte en drive "D" mei in kapasiteit fan 1 terabyte. No, "C" is it systeem, "D" is foar gegevens, de ûntwikkelder beslút logysk en set alle databases dêr yn. Ik haw sels ûnderhâldsplannen ynsteld, ynklusyf backup, foar it gefal (ek al binne wy net ferantwurdlik foar dit). Wier, backups waarden hjir tafoege oan "D". Yn 'e takomst wie it pland om it opnij te konfigurearjen nei wat aparte netwurkboarne.
It projekt begon, adviseurs joegen training oer hoe't se wurkje yn it nije systeem, oerbliuwsels waarden oerdroegen, wat lytse lytse ferbetterings waarden makke, en brûkers begon te wurkjen yn 'e nije ynformaasjebasis.
Alles gie goed oant op in moandeitemoarn doe't ûntdutsen waard dat de databankskiif mist. D'r is gewoan gjin "D" op 'e tsjinner en dat is it.
Fierder ûndersyk die bliken dat dit "server" wie eins de wurkkompjûter fan in lokale systeembehearder. Wier, it hie noch in server-OS. It persoanlike USB-stasjon fan dizze admin is ynplukt op de tsjinner. En sa gie de behearder op fakânsje, naam syn skroef mei, mei as doel der foar de reis filmkes yn te pompen.
Tankewol, hy slagge it net om de databankbestannen te wiskjen en slagge it produktive databank te herstellen.
It is opmerklik dat elkenien wie oer it algemien tefreden mei de prestaasjes fan it systeem leit op in USB-drive. Nimmen klage oer in ûnfoldwaande prestaasjes fan 1C. It wie pas letter dat de holding in mega-projekt begon om alle ynformaasjedatabases oer te bringen nei ien sintralisearre side mei super-servers, opslachsystemen foar in miljoen + roebels, ferfine hypervisors en ûndraaglike 1C-remmen yn alle tûken.
Mar dat is in folslein oar ferhaal...
Boarne: www.habr.com