Alle 1C-ontwikkelaars hebben op de een of andere manier nauwe interactie met IT-diensten en rechtstreeks met systeembeheerders. Maar deze interactie verloopt niet altijd even soepel. Ik wil je hier graag een paar grappige verhalen over vertellen.
Communicatiekanaal met hoge snelheid
De meeste van onze klanten zijn grote holdings met hun eigen grote IT-afdelingen. En klantspecialisten zijn meestal verantwoordelijk voor back-ups van informatiedatabases. Maar er zijn ook relatief kleine organisaties. Speciaal voor hen hebben we een dienst waarmee we alle problemen met betrekking tot de back-up van alles 1C op ons nemen. Dit is het bedrijf waar we het in dit verhaal over zullen hebben.
Er kwam een nieuwe klant ter ondersteuning van 1C en in het contract was onder meer opgenomen dat wij verantwoordelijk waren voor de back-ups, ook al hadden zij een eigen systeembeheerder in dienst. Client-server-database, MS SQL als DBMS. Een vrij standaardsituatie, maar er was toch één nuance: de hoofdbasis was vrij groot, maar de maandelijkse stijging was erg klein. Dat wil zeggen, de database bevatte veel historische gegevens. Rekening houdend met deze functie heb ik als volgt back-uponderhoudsplannen opgezet: op de eerste zaterdag van elke maand werd een volledige back-up gemaakt, deze was behoorlijk zwaar, daarna werd er elke nacht een differentiële kopie gemaakt - een relatief klein volume, en een kopie van het transactielogboek elk uur. Bovendien werden volledige en differentiële kopieën niet alleen gekopieerd naar een netwerkbron, maar ook geüpload naar onze FTP-server. Dit is een verplichte vereiste bij het verlenen van deze dienst.
Dit alles werd met succes geconfigureerd, in gebruik genomen en werkte over het algemeen zonder storingen.
Maar een paar maanden later veranderde de systeembeheerder in deze organisatie. De nieuwe systeembeheerder begon de IT-infrastructuur van het bedrijf geleidelijk opnieuw op te bouwen in overeenstemming met de moderne trends. In het bijzonder verscheen virtualisatie, schijfplanken, toegang werd overal en alles geblokkeerd, enz., wat in het algemeen natuurlijk alleen maar verheugd kan zijn. Maar het verliep niet altijd even soepel voor hem; er waren vaak problemen met de prestaties van 1C, wat voor enige meningsverschillen en misverstanden met onze steun zorgde. Ook moet worden opgemerkt dat onze relatie met hem over het algemeen nogal koud en enigszins gespannen was, wat de spanning alleen maar groter maakte als zich problemen voordeden.
Maar op een ochtend bleek dat de server van deze klant niet beschikbaar was. Ik belde de systeembeheerder om erachter te komen wat er was gebeurd en kreeg als antwoord zoiets als: "Onze server is gecrasht, we werken eraan, niet aan jou." Nou, het is goed dat ze werken. Dit betekent dat de situatie onder controle is. Na de lunch bel ik weer terug, en in plaats van irritatie voel ik al vermoeidheid en apathie in de stem van de beheerder. Ik probeer erachter te komen wat er is gebeurd en kunnen we iets doen om te helpen? Uit het gesprek kwam het volgende naar voren:
Hij verplaatste de server naar een nieuw opslagsysteem met een nieuw samengestelde raid. Maar er ging iets mis en een paar dagen later stortte deze inval veilig in. Of de controller is doorgebrand of dat er iets met de schijven is gebeurd, weet ik niet precies meer, maar alle informatie is onherstelbaar verloren gegaan. En het belangrijkste was dat de netwerkbron met back-ups tijdens verschillende migraties ook op dezelfde disk-array terechtkwam. Dat wil zeggen dat zowel de productieve database zelf als alle reservekopieën ervan verloren zijn gegaan. En het is onduidelijk wat we nu moeten doen.
Doe rustig aan, zeg ik. We hebben je nachtelijke back-up. Als reactie daarop viel er een stilte, waardoor ik besefte dat ik zojuist het leven van een man had gered. We beginnen te bespreken hoe we deze kopie kunnen overbrengen naar een nieuwe, nieuw geïmplementeerde server. Maar ook hier deed zich een probleem voor.
Weet je nog dat ik zei dat de volledige back-up behoorlijk groot was? Niet voor niets deed ik het één keer per maand op zaterdag. Feit is dat het bedrijf een kleine fabriek was, ver buiten de stad en dat hun internet erg matig was. Maandagochtend, dat wil zeggen in het weekend, kon deze kopie nauwelijks naar onze FTP-server worden geüpload. Maar er was geen manier om een dag of twee te wachten totdat het in de tegenovergestelde richting zou worden geladen. Na verschillende mislukte pogingen om het bestand over te zetten, haalde de beheerder de harde schijf rechtstreeks uit de nieuwe server, vond ergens een auto met chauffeur en haastte zich snel naar ons kantoor, gelukkig zijn we nog steeds in dezelfde stad.
Terwijl zij in onze serverruimte stonden te wachten tot de bestanden gekopieerd waren, ontmoetten wij elkaar voor het eerst, bij wijze van spreken, ‘in persoon’, dronken een kop koffie en spraken in een informele setting. Ik sympathiseerde met zijn verdriet en stuurde hem terug met een hele stapel backups, waarmee ik haastig de stopgezette werkzaamheden van het bedrijf herstelde.
Vervolgens werden al onze verzoeken aan de IT-afdeling zeer snel opgelost en ontstonden er geen meningsverschillen meer.
Neem contact op met uw systeembeheerder
Ooit kon ik heel lang geen 1C publiceren voor webtoegang via IIS voor één client. Het leek een gewone taak, maar er was geen manier om alles draaiende te krijgen. Lokale systeembeheerders raakten erbij betrokken en probeerden verschillende instellingen en configuratiebestanden. 1C op internet wilde normaal gesproken op geen enkele manier werken. Er was iets mis met het domeinbeveiligingsbeleid, of met de lokale geavanceerde firewall, of God weet wat nog meer. Bij de N-de iteratie stuurt de beheerder mij een link met de woorden:
- Probeer het opnieuw met behulp van deze instructies. Alles wordt daar tot in detail beschreven. Als het niet werkt, schrijf dan naar de auteur van deze site, misschien kan hij helpen.
‘Nee,’ zeg ik, ‘dat helpt niet.’
- waarom?
— Ik ben de auteur van deze site... (
Als gevolg hiervan hebben we het zonder problemen op Apache gelanceerd. IIS werd nooit verslagen.
Een niveau dieper
We hadden een klant: een klein productiebedrijf. Ze hadden een server, een soort ‘klassieke’ 3 in 1: terminalserver + applicatieserver + databaseserver. Ze werkten in een branchespecifieke configuratie op basis van UPP, er waren ongeveer 15-20 gebruikers en de prestaties van het systeem waren in principe voor iedereen geschikt.
Naarmate de tijd verstreek, werkte alles min of meer stabiel. Maar toen legde Europa sancties op tegen Rusland, waardoor de Russen voornamelijk in eigen land geproduceerde producten begonnen te kopen, en de zaken voor dit bedrijf gingen sterk bergopwaarts. Het aantal gebruikers steeg tot 50-60 personen, er werd een nieuw filiaal geopend en de documentenstroom nam dienovereenkomstig toe. En nu kon de huidige server de sterk toegenomen belasting niet meer aan, en begon 1C, zoals ze zeggen, "te vertragen". Tijdens piekuren werden documenten enkele minuten verwerkt, deden zich blokkeringsfouten voor, duurde het lang voordat formulieren werden geopend en nog veel meer aanverwante diensten. De lokale systeembeheerder veegde alle problemen van tafel met de woorden: “Dit is jouw 1C, jij komt er wel uit.” Wij hebben herhaaldelijk voorgesteld een prestatie-audit van het systeem uit te voeren, maar tot de audit zelf is het nooit gekomen. De klant vroeg eenvoudigweg om aanbevelingen voor het oplossen van problemen.
Nou, ik ging zitten en schreef een nogal lange brief over de noodzaak om de rollen van de terminalserver en de applicatieserver met het DBMS te scheiden (wat we in principe al vele malen eerder hebben gezegd). Ik schreef over DFSS op terminalservers, over gedeeld geheugen, gaf links naar gezaghebbende bronnen en stelde zelfs enkele opties voor apparatuur voor. Deze brief bereikte de machthebbers in het bedrijf, ging terug naar de IT-afdeling met de resoluties “Implementeren” en het ijs was over het algemeen gebroken.
Na enige tijd stuurt de beheerder mij het IP-adres van de nieuwe server en de inloggegevens. Hij zegt dat daar MS SQL- en 1C-servercomponenten worden ingezet en dat de databases moeten worden overgebracht, maar voorlopig alleen naar de DBMS-server, omdat er enkele problemen zijn opgetreden met de 1C-sleutels.
Ik kwam binnen, inderdaad, alle services waren actief, de server was niet erg krachtig, maar oké, ik denk dat het beter is dan niets. Ik zal de databases voorlopig overzetten om de huidige server op de een of andere manier te ontlasten. Ik voltooide alle overdrachten op het afgesproken tijdstip, maar de situatie veranderde niet - nog steeds dezelfde prestatieproblemen. Het is natuurlijk vreemd, laten we de databases in het 1C-cluster registreren en we zullen zien.
Er gaan enkele dagen voorbij, de sleutels zijn niet overgedragen. Ik vraag me af wat het probleem is, alles lijkt eenvoudig: haal het uit de ene server, sluit het aan op een andere, installeer het stuurprogramma en je bent klaar. De beheerder reageert door te zeuren en iets te zeggen over port forwarding, een virtuele server, enzovoort.
Hmm... Virtuele server? Het lijkt erop dat er nooit enige virtualisatie heeft plaatsgevonden en dat is er ook nooit geweest... Ik herinner me een redelijk bekend probleem met de onmogelijkheid om een 1C-serversleutel door te sturen naar een virtuele machine op Hyper-V in Windows Server 2008. En hier er beginnen wat vermoedens bij mij te ontstaan...
Ik open de serverbeheerder - Rollen - er is een nieuwe rol verschenen - Hyper-V. Ik ga naar de Hyper-V-manager, zie één virtuele machine, maak verbinding... En inderdaad... Onze nieuwe databaseserver...
Dus? De instructies van de autoriteiten en mijn aanbevelingen zijn uitgevoerd, de rollen zijn gescheiden. De taak kan worden gesloten.
Na enige tijd gebeurde de huidige crisis, moest het nieuwe filiaal worden gesloten, nam de belasting af en werden de systeemprestaties min of meer draaglijk.
Natuurlijk konden ze de serversleutel niet doorsturen naar de virtuele machine. Als gevolg hiervan bleef alles zoals het is: terminalserver + 1C-cluster op een fysieke machine, databaseserver daar op een virtuele.
En het zou leuk zijn als dit een soort Sharashkin-kantoor was. Dus nee. Een bekend bedrijf waarvan u de producten waarschijnlijk kent en heeft gezien op de relevante afdelingen van alle Lentas en Auchans.
Vakantieschema harde schijf
Een grote holding met ambitieuze plannen om de wereld over te nemen, heeft opnieuw een klein bedrijf gekocht met als doel het op te nemen in zijn megabedrijf. In alle divisies van deze holding werken gebruikers in hun eigen databases, maar met een identieke configuratie. En dus zijn we een klein project gestart om een nieuwe unit in dit systeem op te nemen.
Allereerst is het noodzakelijk om productie- en testdatabases in te zetten. De ontwikkelaar heeft de verbindingsgegevens ontvangen, logt in op de server, ziet MS SQL geïnstalleerd, 1C-server, ziet 2 logische schijven: schijf “C” met een capaciteit van 250 gigabyte en schijf “D” met een capaciteit van 1 terabyte. Welnu, “C” is het systeem, “D” is voor gegevens, de ontwikkelaar beslist logischerwijs en implementeert alle databases daar. Ik heb zelfs onderhoudsplannen opgesteld, inclusief back-up, voor het geval dat (ook al zijn wij hier niet verantwoordelijk voor). Het is waar dat hier back-ups zijn toegevoegd aan "D". In de toekomst was het de bedoeling om het opnieuw te configureren naar een afzonderlijke netwerkbron.
Het project ging van start, consultants gaven training over hoe ze in het nieuwe systeem moesten werken, restjes werden overgedragen, er werden enkele kleine verbeteringen aangebracht en gebruikers gingen aan de slag in de nieuwe informatiebasis.
Alles ging goed totdat op een maandagochtend werd ontdekt dat de databaseschijf ontbrak. Er is eenvoudigweg geen “D” op de server en dat is alles.
Nader onderzoek bracht dit aan het licht: deze ‘server’ was feitelijk de werkcomputer van een lokale systeembeheerder. Toegegeven, het had nog steeds een server-besturingssysteem. Het persoonlijke USB-station van deze beheerder is op de server aangesloten. En dus ging de beheerder op vakantie, met zijn schroef mee, met als doel er films in te pompen voor de reis.
Godzijdank slaagde hij er niet in de databasebestanden te verwijderen en slaagde hij erin de productieve database te herstellen.
Het is opmerkelijk dat iedereen over het algemeen tevreden was met de prestaties van het systeem op een USB-stick. Niemand klaagde over onbevredigende prestaties van 1C. Pas later begon de holding aan een megaproject om alle informatiedatabases over te brengen naar één gecentraliseerde site met superservers, opslagsystemen voor meer dan een miljoen roebel, geavanceerde hypervisors en ondraaglijke 1C-remmen in alle vestigingen.
Maar dat is een heel ander verhaal...
Bron: www.habr.com