Alle 1C-utviklere samhandler på en eller annen måte tett med IT-tjenester og direkte med systemadministratorer. Men dette samspillet går ikke alltid knirkefritt. Jeg vil gjerne fortelle deg noen morsomme historier om dette.
Høyhastighets kommunikasjonskanal
De fleste av våre kunder er store bedrifter med egne store IT-avdelinger. Og klientspesialister er vanligvis ansvarlige for sikkerhetskopier av informasjonsdatabaser. Men det er også relativt små organisasjoner. Spesielt for dem har vi en tjeneste der vi tar på oss alle problemer knyttet til backup av alt 1C. Dette er selskapet vi skal snakke om i denne historien.
En ny klient kom for å støtte 1C og kontrakten inneholdt blant annet en klausul om at vi var ansvarlige for sikkerhetskopiering, selv om de hadde en egen systemadministrator på staben. Klient-tjener database, MS SQL som DBMS. En ganske standard situasjon, men det var fortsatt en nyanse: hovedbasen var ganske stor, men den månedlige økningen var veldig liten. Det vil si at databasen inneholdt mye historisk data. Med denne funksjonen i betraktning, satte jeg opp backup vedlikeholdsplaner som følger: den første lørdagen i hver måned ble det laget en fullstendig sikkerhetskopi, den var ganske tung, deretter ble det laget en differensiell kopi hver natt - et relativt lite volum, og en kopi av transaksjonsloggen hver time. Dessuten ble fullstendige og differensielle kopier ikke bare kopiert til en nettverksressurs, men også lastet opp til FTP-serveren vår. Dette er et obligatorisk krav når du leverer denne tjenesten.
Alt dette ble vellykket konfigurert, satt i drift og fungerte generelt uten feil.
Men noen måneder senere endret systemadministratoren i denne organisasjonen seg. Den nye systemadministratoren begynte gradvis å gjenoppbygge selskapets IT-infrastruktur i samsvar med moderne trender. Spesielt dukket det opp virtualisering, diskhyller, tilgang ble blokkert overalt og alt, etc., som i det generelle tilfellet selvfølgelig ikke kan annet enn å glede seg. Men ting gikk ikke alltid glatt for ham; det var ofte problemer med ytelsen til 1C, noe som forårsaket noen uenigheter og misforståelser med vår støtte. Det skal også bemerkes at vårt forhold til ham generelt var ganske kaldt og noe anstrengt, noe som bare økte spenningsgraden dersom det skulle oppstå problemer.
Men en morgen viste det seg at denne klientens server var utilgjengelig. Jeg ringte systemadministratoren for å finne ut hva som skjedde og fikk som svar noe sånt som "Serveren vår har krasjet, vi jobber med det, ikke opp til deg." Vel, det er bra at de fungerer. Dette betyr at situasjonen er under kontroll. Etter lunsj ringer jeg tilbake igjen, og i stedet for irritasjon kan jeg allerede føle tretthet og apati i admins stemme. Jeg prøver å finne ut hva som skjedde og er det noe vi kan gjøre for å hjelpe? Som et resultat av samtalen kom følgende frem:
Han flyttet serveren til et nytt lagringssystem med et nylig satt sammen raid. Men noe gikk galt, og noen dager senere kollapset dette raidet trygt. Om kontrolleren ble utbrent eller noe skjedde med diskene, husker jeg ikke nøyaktig, men all informasjonen gikk uopprettelig tapt. Og hovedsaken var at nettverksressursen med backup også havnet på samme diskarray under ulike migrasjoner. Det vil si at både selve den produktive databasen og alle sikkerhetskopiene gikk tapt. Og det er uklart hva du skal gjøre nå.
Rolig, sier jeg. Vi har din nattlige backup. Som svar ble det stillhet, hvorved jeg innså at jeg nettopp hadde reddet en manns liv. Vi begynner å diskutere hvordan du overfører denne kopien til en ny, nylig distribuert server. Men også her oppsto et problem.
Husker du da jeg sa at hele sikkerhetskopien var ganske stor? Det var ikke for ingenting jeg gjorde det en gang i måneden på lørdager. Faktum er at selskapet var et lite anlegg, som lå langt utenfor byen og deres internett var veldig så som så. Mandag morgen, altså over helgen, rakk denne kopien så vidt å bli lastet opp til vår FTP-server. Men det var ingen måte å vente en dag eller to på at den skulle lastes i motsatt retning. Etter flere mislykkede forsøk på å overføre filen, tok administratoren ut harddisken direkte fra den nye serveren, fant en bil med sjåfør et sted og skyndte seg raskt til kontoret vårt, heldigvis er vi fortsatt i samme by.
Mens de sto på serverrommet vårt og ventet på at filene skulle kopieres, møttes vi for første gang så å si «personlig», drakk en kopp kaffe og snakket i uformelle omgivelser. Jeg sympatiserte med sorgen hans og sendte ham tilbake med en hel skrue av sikkerhetskopier, og raskt gjenopprettet det stoppede arbeidet til selskapet.
Deretter ble alle våre forespørsler til IT-avdelingen løst veldig raskt og det oppsto ikke flere uenigheter.
Kontakt systemadministratoren din
En gang, i veldig lang tid, kunne jeg ikke publisere 1C for nettilgang via IIS for én klient. Det virket som en vanlig oppgave, men det var ingen måte å få alt til å gå på. Lokale systemadministratorer ble involvert og prøvde forskjellige innstillinger og konfigurasjonsfiler. 1C på nettet ønsket normalt ikke å fungere på noen måte. Noe var galt, enten med domenesikkerhetspolicyer, eller med den lokale sofistikerte brannmuren, eller gud vet hva mer. På den n'te iterasjonen sender administratoren meg en lenke med ordene:
- Prøv igjen ved å bruke disse instruksjonene. Alt er beskrevet der ganske detaljert. Hvis det ikke fungerer, skriv til forfatteren av denne siden, kanskje han kan hjelpe.
"Nei," sier jeg, "det hjelper ikke."
- Hvorfor?
– Jeg er forfatteren av denne siden... (
Som et resultat lanserte vi den på Apache uten problemer. IIS ble aldri beseiret.
Ett nivå dypere
Vi hadde en kunde - en liten produksjonsbedrift. De hadde en server, en slags "klassisk" 3 i 1: terminalserver + applikasjonsserver + databaseserver. De jobbet i en eller annen bransjespesifikk konfigurasjon basert på UPP, det var ca 15-20 brukere, og ytelsen til systemet passet i prinsippet alle.
Ettersom tiden gikk fungerte alt mer eller mindre stabilt. Men så innførte Europa sanksjoner mot Russland, som et resultat av at russerne begynte å kjøpe hovedsakelig innenlandsproduserte produkter, og virksomheten for dette selskapet gikk kraftig oppoverbakke. Antall brukere økte til 50-60 personer, en ny filial ble åpnet, og dokumentflyten økte tilsvarende. Og nå kunne den nåværende serveren ikke lenger takle den kraftig økte belastningen, og 1C begynte, som de sier, å "sakke farten". I rushtiden ble dokumenter behandlet i flere minutter, blokkeringsfeil oppstod, skjemaer tok lang tid å åpne, og hele den andre buketten av relaterte tjenester. Den lokale systemadministratoren børstet bort alle problemene og sa: "Dette er din 1C, du vil finne ut av det." Vi har gjentatte ganger foreslått å gjennomføre en forvaltningsrevisjon av systemet, men det kom aldri til selve tilsynet. Klienten ba ganske enkelt om anbefalinger om hvordan problemer kan løses.
Vel, jeg satte meg ned og skrev et ganske langt brev om behovet for å skille rollene til terminalserveren og applikasjonsserveren med DBMS (som vi i prinsippet allerede har sagt mange ganger før). Jeg skrev om DFSS på terminalservere, om delt minne, ga lenker til autoritative kilder og foreslo til og med noen alternativer for utstyr. Dette brevet nådde makthaverne i selskapet, gikk tilbake til IT-avdelingen med resolusjonene «Implement» og isen var generelt brutt.
Etter en stund sender administratoren meg IP-adressen til den nye serveren og påloggingsinformasjon. Han forteller at MS SQL- og 1C-serverkomponenter er utplassert der, og databasene må overføres, men foreløpig kun til DBMS-serveren, siden det har oppstått noen problemer med 1C-nøklene.
Jeg kom inn, faktisk, alle tjenestene kjørte, serveren var ikke veldig kraftig, men ok, jeg tror det er bedre enn ingenting. Jeg vil overføre databasene for nå for på en eller annen måte å avlaste den nåværende serveren. Jeg fullførte alle overføringene til avtalt tid, men situasjonen endret seg ikke - fortsatt de samme ytelsesproblemene. Det er rart, selvfølgelig, vel, la oss registrere databasene i 1C-klyngen, så får vi se.
Det går flere dager, nøklene er ikke overført. Jeg lurer på hva problemet er, alt ser ut til å være enkelt - ta den ut av en server, koble den til en annen, installer driveren og du er ferdig. Administratoren svarer med å mase og si noe om portvideresending, en virtuell server og så videre.
Hmm... Virtuell server? Det ser ut til at det aldri har vært noen virtualisering og det har aldri vært noen... Jeg husker et ganske velkjent problem med umuligheten av å videresende en 1C servernøkkel til en virtuell maskin på Hyper-V i Windows Server 2008. Og her Det begynner å danne seg noen mistanker i meg...
Jeg åpner serverbehandleren - Roller - en ny rolle har dukket opp - Hyper-V. Jeg går til Hyper-V-manageren, ser en virtuell maskin, kobler til... Og faktisk... Vår nye databaseserver...
Hva så? Myndighetenes instrukser og mine anbefalinger er utført, rollene er skilt. Oppgaven kan lukkes.
Etter en tid skjedde den nå krise, den nye filialen måtte stenges, belastningen reduserte, og systemytelsen ble mer eller mindre tålelig.
Vel, selvfølgelig, de kunne ikke videresende servernøkkelen til den virtuelle maskinen. Som et resultat ble alt stående som det er: terminalserver + 1C-klynge på en fysisk maskin, databaseserver der i en virtuell.
Og det ville vært fint om dette var en slags Sharashkins kontor. Så nei. Et velkjent selskap hvis produkter du sikkert kjenner og har sett i de relevante avdelingene til alle Lentas og Auchans.
Harddisk ferieplan
Et stort holdingselskap med ambisiøse planer om å ta over verden har igjen kjøpt et lite selskap med mål om å inkludere det i sitt megaselskap. I alle divisjoner av denne beholdningen arbeider brukerne i sine egne databaser, men med en identisk konfigurasjon. Så vi startet et lite prosjekt for å inkludere en ny enhet i dette systemet.
Først av alt er det nødvendig å distribuere produksjons- og testdatabaser. Utvikleren mottok tilkoblingsdataene, logger på serveren, ser MS SQL installert, 1C server, ser 2 logiske stasjoner: stasjon "C" med en kapasitet på 250 gigabyte og stasjon "D" med en kapasitet på 1 terabyte. Vel, "C" er systemet, "D" er for data, utvikleren bestemmer logisk og distribuerer alle databasene der. Jeg setter til og med opp vedlikeholdsplaner, inkludert backup, for sikkerhets skyld (selv om vi ikke er ansvarlige for dette). Riktignok ble sikkerhetskopier lagt til "D". I fremtiden var det planlagt å rekonfigurere den til en egen nettverksressurs.
Prosjektet startet, konsulenter ga opplæring i hvordan man jobber i det nye systemet, rester ble overført, noen mindre forbedringer ble gjort og brukere begynte å jobbe i den nye informasjonsbasen.
Alt gikk bra inntil det en mandag morgen ble oppdaget at databasedisken manglet. Det er rett og slett ingen "D" på serveren, og det er det.
Ytterligere undersøkelser avslørte dette: denne "serveren" var faktisk arbeidsdatamaskinen til en lokal systemadministrator. Riktignok hadde den fortsatt et server-OS. Denne administratorens personlige USB-stasjon ble koblet til serveren. Og så dro administratoren på ferie og tok med seg skruen, med mål om å pumpe inn filmer til turen.
Takk Gud, han klarte ikke å slette databasefilene og klarte å gjenopprette den produktive databasen.
Det er bemerkelsesverdig at alle generelt var fornøyd med ytelsen til systemet som ligger på en USB-stasjon. Ingen klaget på utilfredsstillende ytelse av 1C. Det var først senere at beholdningen startet et megaprosjekt for å overføre alle informasjonsdatabaser til et enkelt sentralisert nettsted med superservere, lagringssystemer for en million+ rubler, sofistikerte hypervisorer og uutholdelige 1C-bremser i alle grener.
Men det er en helt annen historie...
Kilde: www.habr.com