Alle 1C-udviklere interagerer på den ene eller anden måde tæt med IT-tjenester og direkte med systemadministratorer. Men denne interaktion går ikke altid glat. Jeg vil gerne fortælle dig et par sjove historier om dette.
Højhastighedskommunikationskanal
De fleste af vores kunder er store bedrifter med egne store it-afdelinger. Og klientspecialister er normalt ansvarlige for sikkerhedskopier af informationsdatabaser. Men der er også relativt små organisationer. Specielt for dem har vi en service, ifølge hvilken vi påtager os alle problemer relateret til backup af alt 1C. Dette er virksomheden, vi vil tale om i denne historie.
En ny kunde kom til at understøtte 1C, og kontrakten indeholdt blandt andet en klausul om, at vi var ansvarlige for backups, selvom de havde deres egen systemadministrator på personalet. Klient-server-database, MS SQL som DBMS. En ret standardsituation, men der var stadig en nuance: Hovedbasen var ret stor, men den månedlige stigning var meget lille. Det vil sige, at databasen indeholdt en masse historiske data. Med denne funktion i betragtning satte jeg backup-vedligeholdelsesplaner op som følger: den første lørdag i hver måned blev der lavet en fuld backup, den var ret tung, derefter blev der lavet en differentiel kopi hver nat - et relativt lille volumen og en kopi af transaktionsloggen hver time. Desuden blev hele og differentielle kopier ikke kun kopieret til en netværksressource, men også uploadet til vores FTP-server. Dette er et obligatorisk krav, når du leverer denne service.
Alt dette blev konfigureret, sat i drift og fungerede generelt uden fejl.
Men et par måneder senere ændrede systemadministratoren i denne organisation sig. Den nye systemadministrator begyndte gradvist at genopbygge virksomhedens it-infrastruktur i overensstemmelse med moderne trends. Især dukkede virtualisering op, diskhylder, adgang blev blokeret overalt og alting osv., som i det generelle tilfælde selvfølgelig ikke kan andet end at glæde sig. Men tingene gik ikke altid glat for ham; der var ofte problemer med 1C's ydeevne, hvilket forårsagede nogle uenigheder og misforståelser med vores support. Det skal også bemærkes, at vores forhold til ham generelt var ret koldt og noget anstrengt, hvilket kun øgede spændingsgraden, hvis der skulle opstå problemer.
Men en morgen viste det sig, at denne klients server ikke var tilgængelig. Jeg ringede til systemadministratoren for at finde ud af, hvad der skete og modtog som et svar noget i stil med "Vores server er gået ned, vi arbejder på det, ikke op til dig." Nå, det er godt, at de virker. Det betyder, at situationen er under kontrol. Efter frokost ringer jeg tilbage igen, og i stedet for irritation kan jeg allerede mærke træthed og apati i administratorens stemme. Jeg prøver at finde ud af, hvad der skete, og er der noget, vi kan gøre for at hjælpe? Som et resultat af samtalen kom følgende frem:
Han flyttede serveren til et nyt lagersystem med et nyligt samlet raid. Men noget gik galt, og et par dage senere kollapsede dette raid sikkert. Om controlleren brændte ud, eller om der skete noget med diskene, husker jeg ikke præcist, men al information gik uigenkaldeligt tabt. Og hovedsagen var, at netværksressourcen med backups også endte på det samme diskarray under forskellige migreringer. Det vil sige, at både selve den produktive database og alle dens sikkerhedskopier gik tabt. Og det er uklart, hvad man skal gøre nu.
Rolig, siger jeg. Vi har din natlige backup. Som svar blev der tavshed, hvorved jeg indså, at jeg lige havde reddet en mands liv. Vi begynder at diskutere, hvordan man overfører denne kopi til en ny, nyligt installeret server. Men også her opstod et problem.
Kan du huske, da jeg sagde, at den fulde backup var ret stor? Det var ikke for ingenting, at jeg gjorde det en gang om måneden om lørdagen. Faktum er, at virksomheden var et lille anlæg, som lå langt uden for byen, og deres internet var meget halvdårligt. Mandag morgen, altså i weekenden, nåede denne kopi knap at blive uploadet til vores FTP-server. Men der var ingen måde at vente en dag eller to på, før den blev læsset i den modsatte retning. Efter flere mislykkede forsøg på at overføre filen, tog administratoren harddisken direkte fra den nye server, fandt en bil med en chauffør et sted og skyndte sig hurtigt til vores kontor, heldigvis er vi stadig i samme by.
Mens de stod i vores serverrum og ventede på, at filerne skulle kopieres, mødtes vi for første gang så at sige "personligt", drak en kop kaffe og snakkede i uformelle rammer. Jeg sympatiserede med hans sorg og sendte ham tilbage med en fuld skrue af sikkerhedskopier, og genoprettede hurtigt det standsede arbejde i virksomheden.
Efterfølgende blev alle vores henvendelser til IT-afdelingen løst meget hurtigt, og der opstod ikke flere uenigheder.
Kontakt din systemadministrator
Engang kunne jeg i meget lang tid ikke udgive 1C til webadgang via IIS for én klient. Det virkede som en almindelig opgave, men der var ingen måde at få alt til at køre på. Lokale systemadministratorer blev involveret og prøvede forskellige indstillinger og konfigurationsfiler. 1C på nettet ønskede normalt ikke at fungere på nogen måde. Noget var galt, enten med domænesikkerhedspolitikker eller med den lokale sofistikerede firewall, eller gud ved hvad ellers. I den n'te iteration sender administratoren mig et link med ordene:
- Prøv igen ved at følge disse instruktioner. Alt er beskrevet ret detaljeret der. Hvis det ikke virker, så skriv til forfatteren af dette websted, måske kan han hjælpe.
"Nej," siger jeg, "det hjælper ikke."
- Hvorfor?
— Jeg er forfatteren af dette websted... (
Som et resultat lancerede vi det på Apache uden problemer. IIS blev aldrig besejret.
Et niveau dybere
Vi havde en kunde - en lille produktionsvirksomhed. De havde en server, en slags "klassisk" 3 i 1: terminalserver + applikationsserver + databaseserver. De arbejdede i en eller anden branchespecifik konfiguration baseret på UPP, der var omkring 15-20 brugere, og systemets ydeevne passede i princippet alle.
Som tiden gik, fungerede alt mere eller mindre stabilt. Men så indførte Europa sanktioner mod Rusland, som et resultat af, at russerne begyndte at købe hovedsageligt indenlandsk producerede produkter, og forretningen for denne virksomhed gik kraftigt op ad bakke. Antallet af brugere steg til 50-60 personer, en ny filial blev åbnet, og dokumentflowet steg tilsvarende. Og nu kunne den nuværende server ikke længere klare den kraftigt øgede belastning, og 1C begyndte, som de siger, at "sænke farten". I myldretiden blev dokumenter behandlet i flere minutter, der opstod blokeringsfejl, formularer tog lang tid at åbne, og hele den anden buket af relaterede tjenester. Den lokale systemadministrator fjernede alle problemerne og sagde: "Dette er din 1C, du finder ud af det." Vi har gentagne gange foreslået at gennemføre en forvaltningsrevision af systemet, men det kom aldrig til selve revisionen. Klienten bad blot om anbefalinger til, hvordan man løser problemer.
Nå, jeg satte mig ned og skrev et ret langt brev om behovet for at adskille rollerne for terminalserveren og applikationsserveren med DBMS (hvilket vi i princippet allerede har sagt mange gange før). Jeg skrev om DFSS på terminalservere, om Shared Memory, gav links til autoritative kilder og foreslog endda nogle muligheder for udstyr. Dette brev nåede frem til magthaverne i virksomheden, gik tilbage til IT-afdelingen med beslutningerne "Implementer", og isen var generelt brudt.
Efter nogen tid sender administratoren mig IP-adressen på den nye server og login-oplysninger. Han fortæller, at MS SQL- og 1C-serverkomponenter er installeret der, og databaserne skal overføres, men indtil videre kun til DBMS-serveren, da der er opstået nogle problemer med 1C-nøglerne.
Jeg kom ind, ja, alle tjenesterne kørte, serveren var ikke særlig kraftfuld, men ok, jeg synes, det er bedre end ingenting. Jeg overfører databaserne for nu for på en eller anden måde at aflaste den nuværende server. Jeg gennemførte alle overførsler til det aftalte tidspunkt, men situationen ændrede sig ikke - stadig de samme præstationsproblemer. Det er selvfølgelig mærkeligt, ja, lad os registrere databaserne i 1C-klyngen, og vi vil se.
Der går flere dage, nøglerne er ikke overført. Jeg spekulerer på, hvad problemet er, alt ser ud til at være enkelt - tag det ud af en server, sæt det i en anden, installer driveren, og du er færdig. Admin svarer ved at bøvle og sige noget om port forwarding, en virtuel server og så videre.
Hmm... Virtuel server? Det ser ud til, at der aldrig har været nogen virtualisering, og der har aldrig været nogen... Jeg husker et ret velkendt problem med umuligheden af at videresende en 1C servernøgle til en virtuel maskine på Hyper-V i Windows Server 2008. Og her nogle mistanker begynder at opstå i mig...
Jeg åbner servermanageren - Roller - en ny rolle er dukket op - Hyper-V. Jeg går til Hyper-V-manageren, ser en virtuel maskine, forbinder... Og faktisk... Vores nye databaseserver...
Og hvad så? Myndighedernes anvisninger og mine anbefalinger er blevet udført, rollerne er adskilt. Opgaven kan lukkes.
Efter nogen tid skete den nu krise, den nye filial måtte lukkes, belastningen faldt, og systemets ydeevne blev mere eller mindre tålelig.
Nå, selvfølgelig kunne de ikke videresende servernøglen til den virtuelle maskine. Som et resultat blev alt efterladt som det er: terminalserver + 1C-klynge på en fysisk maskine, databaseserver der i en virtuel.
Og det ville være rart, hvis dette var en slags sharashkins kontor. Så nej. Et velkendt firma, hvis produkter du sikkert kender og har set i de relevante afdelinger i alle Lentas og Auchans.
Harddisk ferieplan
Et stort holdingselskab med ambitiøse planer om at overtage verden har igen købt et lille selskab med det mål at inkludere det i sit megaselskab. I alle afdelinger af denne bedrift arbejder brugerne i deres egne databaser, men med en identisk konfiguration. Så vi startede et lille projekt for at inkludere en ny enhed i dette system.
Først og fremmest er det nødvendigt at implementere produktions- og testdatabaser. Udvikleren modtog forbindelsesdataene, logger ind på serveren, ser MS SQL installeret, 1C server, ser 2 logiske drev: drev "C" med en kapacitet på 250 gigabyte og drev "D" med en kapacitet på 1 terabyte. Nå, "C" er systemet, "D" er for data, udvikleren bestemmer logisk og implementerer alle databaserne der. Jeg opsætter endda vedligeholdelsesplaner, inklusive backup, for en sikkerheds skyld (selvom vi ikke er ansvarlige for dette). Sandt nok blev sikkerhedskopier tilføjet her til "D". I fremtiden var det planlagt at omkonfigurere det til en separat netværksressource.
Projektet startede, konsulenter underviste i, hvordan man arbejder i det nye system, rester blev overført, nogle mindre forbedringer blev foretaget, og brugerne begyndte at arbejde i den nye informationsbase.
Alt gik godt indtil en mandag morgen, hvor det blev opdaget, at databasedisken manglede. Der er simpelthen ikke noget "D" på serveren, og det er det.
Yderligere undersøgelser afslørede dette: denne "server" var faktisk en lokal systemadministrators arbejdscomputer. Sandt nok havde den stadig et server-OS. Denne administrators personlige USB-drev blev tilsluttet serveren. Og så tog administratoren på ferie og tog sin skrue med sig, med det mål at pumpe film ind til turen.
Gudskelov formåede han ikke at slette databasefilerne og formåede at genoprette den produktive database.
Det er bemærkelsesværdigt, at alle generelt var tilfredse med ydeevnen af systemet placeret på et USB-drev. Ingen klagede over utilfredsstillende ydeevne af 1C. Det var først senere, at bedriften påbegyndte et megaprojekt for at overføre alle informationsdatabaser til et enkelt centraliseret websted med superservere, lagersystemer til en million+ rubler, sofistikerede hypervisorer og uudholdelige 1C-bremser i alle grene.
Men det er en helt anden historie...
Kilde: www.habr.com