Kaikki 1C-kehittäjät ovat tavalla tai toisella tiiviissä vuorovaikutuksessa IT-palvelujen ja suoraan järjestelmänvalvojien kanssa. Mutta tämä vuorovaikutus ei aina suju sujuvasti. Haluaisin kertoa sinulle muutaman hauskan tarinan tästä.
Nopea viestintäkanava
Suurin osa asiakkaistamme on suuria omistuksia, joilla on omat suuret IT-osastot. Ja asiakasasiantuntijat ovat yleensä vastuussa tietokantojen varmuuskopioista. Mutta on myös suhteellisen pieniä organisaatioita. Erityisesti heille on tarjolla palvelu, jonka mukaan otamme itsellemme kaikki 1C:n varmuuskopiointiin liittyvät asiat. Tämä on yritys, josta puhumme tässä tarinassa.
Uusi asiakas tuli tukemaan 1C:tä ja muun muassa sopimuksessa oli lauseke, että olemme vastuussa varmuuskopioinnista, vaikka heillä oli oma järjestelmänvalvoja. Asiakas-palvelin-tietokanta, MS SQL DBMS:nä. Melko tavallinen tilanne, mutta yksi vivahde silti oli: pääkanta oli melko suuri, mutta kuukausikorotus oli hyvin pieni. Eli tietokanta sisälsi paljon historiallista tietoa. Tämän ominaisuuden huomioon ottaen tein varmuuskopioiden ylläpitosuunnitelmat seuraavasti: jokaisen kuukauden ensimmäisenä lauantaina tehtiin täysi varmuuskopio, se oli melko raskas, sitten tehtiin joka ilta differentiaalikopio - suhteellisen pieni määrä ja kopio tapahtumalokista tunnin välein. Lisäksi täydellisiä ja erillisiä kopioita ei vain kopioitu verkkoresurssiin, vaan ne myös ladattiin FTP-palvelimellemme. Tämä on pakollinen vaatimus tätä palvelua tarjottaessa.
Kaikki tämä konfiguroitiin onnistuneesti, otettiin käyttöön ja toimi yleensä ilman vikoja.
Mutta muutamaa kuukautta myöhemmin tämän organisaation järjestelmänvalvoja vaihtui. Uusi järjestelmävastaava ryhtyi vähitellen rakentamaan uudelleen yrityksen IT-infrastruktuuria nykyajan trendien mukaisesti. Erityisesti ilmestyi virtualisointi, levyhyllyt, pääsy estettiin kaikkialla ja kaikesta jne., mikä yleensä voi tietysti vain iloita. Mutta asiat eivät aina sujuneet hänelle hyvin; 1C:n toiminnassa oli usein ongelmia, mikä aiheutti erimielisyyksiä ja väärinkäsityksiä tukemme kanssa. On myös huomattava, että suhteemme hänen kanssaan oli yleensä melko kylmä ja hieman jännittynyt, mikä vain lisäsi jännitystä mahdollisten ongelmien ilmetessä.
Mutta eräänä aamuna kävi ilmi, että tämän asiakkaan palvelin ei ollut käytettävissä. Soitin järjestelmänvalvojalle selvittääkseni mitä tapahtui ja sain vastaukseksi jotain "Palvelimemme on kaatunut, työskentelemme asian parissa, ei sinusta." No hyvä että toimivat. Tämä tarkoittaa, että tilanne on hallinnassa. Lounaan jälkeen soitan uudestaan ja ärsytyksen sijaan tunnen jo uupumusta ja apatiaa adminin äänessä. Yritän selvittää, mitä tapahtui, ja voimmeko tehdä jotain auttaaksemme? Keskustelun tuloksena selvisi seuraavaa:
Hän siirsi palvelimen uuteen tallennusjärjestelmään juuri kootun raidin avulla. Mutta jotain meni pieleen ja muutamaa päivää myöhemmin tämä ratsastus romahti turvallisesti. En muista tarkasti, palaiko ohjain vai tapahtuiko levyille jotain, mutta kaikki tiedot katosivat peruuttamattomasti. Ja pääasia oli, että myös verkkoresurssi varmuuskopioineen päätyi eri migraatioiden aikana samalle levyryhmälle. Eli sekä itse tuottava tietokanta että kaikki sen varmuuskopiot katosivat. Ja nyt on epäselvää, mitä tehdä.
Rauhoitu, sanon minä. Meillä on iltainen varmuuskopiosi. Vastauksena vallitsi hiljaisuus, jonka kautta tajusin, että olin juuri pelastanut miehen hengen. Alamme keskustella siitä, kuinka tämä kopio siirretään uuteen, juuri käyttöön otettuun palvelimeen. Mutta tässäkin ilmeni ongelma.
Muistatko, kun sanoin, että koko varmuuskopio oli melko suuri? Ei turhaan tein sen kerran kuukaudessa lauantaisin. Tosiasia on, että yritys oli pieni tehdas, joka sijaitsi kaukana kaupungin ulkopuolella ja heidän Internet oli hyvin niin. Maanantaiaamuun mennessä, eli viikonloppuna, tämä kopio tuskin onnistui lataamaan FTP-palvelimellemme. Mutta ei ollut mitään mahdollisuutta odottaa päivää tai kahta, jotta se latautuisi vastakkaiseen suuntaan. Useiden epäonnistuneiden tiedoston siirtoyritysten jälkeen järjestelmänvalvoja otti kovalevyn suoraan uudelta palvelimelta, löysi jostain auton kuljettajalla ja ryntäsi nopeasti toimistollemme, onneksi olemme edelleen samassa kaupungissa.
Kun he seisoivat palvelinhuoneessamme ja odottivat tiedostojen kopioimista, tapasimme ensimmäistä kertaa niin sanotusti "henkilökohtaisesti", joimme kupin kahvia ja juttelimme epävirallisessa ympäristössä. Tunsin myötätuntoa hänen suruaan ja lähetin hänet takaisin täyden varmuuskopion kanssa, palauttaen kiireesti yrityksen pysähtyneen työn.
Myöhemmin kaikki pyyntömme IT-osastolle ratkaistiin erittäin nopeasti, eikä erimielisyyksiä enää syntynyt.
Ota yhteyttä järjestelmänvalvojaan
Kerran, hyvin pitkään, en voinut julkaista 1C:tä verkkokäyttöä varten IIS:n kautta yhdelle asiakkaalle. Se vaikutti tavalliselta tehtävältä, mutta kaikkea ei ollut mahdollista saada toimimaan. Paikalliset järjestelmänvalvojat osallistuivat ja kokeilivat erilaisia asetuksia ja konfiguraatiotiedostoja. 1C verkossa ei normaalisti halunnut toimia millään tavalla. Jotain oli vialla, joko verkkotunnuksen suojauskäytännöissä, paikallisessa kehittyneessä palomuurissa tai Jumala tietää missä muussa. N:nnessä iteraatiossa järjestelmänvalvoja lähettää minulle linkin sanoilla:
- Yritä uudelleen näiden ohjeiden mukaan. Siellä on kaikki kuvattu melko yksityiskohtaisesti. Jos se ei toimi, kirjoita tämän sivuston kirjoittajalle, ehkä hän voi auttaa.
"Ei", sanon, "se ei auta."
- Miksi ei?
— Olen tämän sivuston kirjoittaja... (
Tämän seurauksena käynnistimme sen Apachessa ilman ongelmia. IIS ei koskaan voitettu.
Yksi taso syvemmälle
Meillä oli asiakas - pieni tuotantoyritys. Heillä oli palvelin, eräänlainen "klassinen" 3 in 1: päätepalvelin + sovelluspalvelin + tietokantapalvelin. He työskentelivät jossain toimialakohtaisessa UPP-pohjaisessa kokoonpanossa, käyttäjiä oli noin 15-20 ja järjestelmän suorituskyky sopi periaatteessa kaikille.
Ajan myötä kaikki toimi enemmän tai vähemmän vakaasti. Mutta sitten Eurooppa määräsi pakotteita Venäjää vastaan, minkä seurauksena venäläiset alkoivat ostaa pääasiassa kotimaisia tuotteita, ja tämän yrityksen liiketoiminta nousi jyrkästi. Käyttäjämäärä nousi 50-60 henkilöön, uusi konttori avattiin ja asiakirjavirta kasvoi vastaavasti. Ja nyt nykyinen palvelin ei enää pystynyt selviytymään jyrkästi lisääntyneestä kuormituksesta, ja 1C alkoi, kuten sanotaan, "hidastua". Ruuhka-aikoina asiakirjoja käsiteltiin useita minuutteja, tapahtui estovirheitä, lomakkeiden avautuminen kesti kauan ja koko muu kimppu asiaan liittyviä palveluita. Paikallinen järjestelmänvalvoja selvitti kaikki ongelmat ja sanoi: "Tämä on sinun 1C, sinä selvität sen." Olemme toistuvasti ehdottaneet järjestelmän suorituskyvyn tarkastuksen suorittamista, mutta se ei koskaan päässyt itse tarkastukseen. Asiakas pyysi vain suosituksia ongelmien korjaamiseksi.
No, istuin alas ja kirjoitin melko pitkän kirjeen tarpeesta erottaa päätepalvelimen ja sovelluspalvelimen roolit DBMS:n kanssa (jotka olemme periaatteessa sanoneet jo monta kertaa aiemmin). Kirjoitin DFSS:stä päätepalvelimissa, jaetusta muistista, tarjosin linkkejä arvovaltaisiin lähteisiin ja jopa ehdotin joitain vaihtoehtoja laitteille. Tämä kirje tavoitti yrityksen vallanpitäjät, palasi IT-osastolle päätöslauselmilla "Toteuta" ja jää oli yleensä rikki.
Jonkin ajan kuluttua järjestelmänvalvoja lähettää minulle uuden palvelimen IP-osoitteen ja kirjautumistiedot. Hän sanoo, että siellä on otettu käyttöön MS SQL- ja 1C-palvelinkomponentteja ja tietokannat on siirrettävä, mutta toistaiseksi vain DBMS-palvelimelle, koska 1C-avaimien kanssa on ilmennyt ongelmia.
Tulin sisään, todellakin, kaikki palvelut olivat käynnissä, palvelin ei ollut kovin tehokas, mutta ok, mielestäni se on parempi kuin ei mitään. Siirrän tietokannat toistaiseksi, jotta voin jollakin tavalla keventää nykyistä palvelinta. Tein kaikki siirrot sovittuna aikana, mutta tilanne ei muuttunut - edelleen samat suorituskykyongelmat. Se on tietysti outoa, no, rekisteröidään tietokannat 1C-klusteriin ja katsotaan.
Useita päiviä kuluu, avaimia ei ole siirretty. Ihmettelen mikä ongelma on, kaikki näyttää olevan yksinkertaista - ota se pois palvelimelta, kytke se toiseen, asenna ohjain ja olet valmis. Järjestelmänvalvoja vastaa hämmentämällä ja sanomalla jotain portin edelleenohjauksesta, virtuaalipalvelimesta ja niin edelleen.
Hmm... Virtuaalinen palvelin? Näyttää siltä, että virtualisointia ei ole koskaan ollut eikä koskaan ollut... Muistan melko hyvin tunnetun ongelman, joka liittyi mahdottomuuteen välittää 1C-palvelinavain virtuaalikoneeseen Hyper-V:ssä Windows Server 2008:ssa. Ja tässä minussa alkaa syntyä epäilyksiä...
Avaan palvelinhallinnan - Rolit - uusi rooli on ilmestynyt - Hyper-V. Siirryn Hyper-V-hallintaan, näen yhden virtuaalikoneen, muodostan yhteyden... Ja todellakin... Uusi tietokantapalvelimemme...
Mitä sitten? Viranomaisten ohjeita ja suosituksiani on toteutettu, roolit on erotettu. Tehtävän voi sulkea.
Jonkin ajan kuluttua tuli nyt kriisi, uusi haara jouduttiin sulkemaan, kuormitus väheni ja järjestelmän suorituskyky muuttui jokseenkin siedettäväksi.
Tietenkin he eivät voineet välittää palvelinavainta virtuaalikoneeseen. Tuloksena kaikki jätettiin ennalleen: päätepalvelin + 1C-klusteri fyysisessä koneessa, tietokantapalvelin siellä virtuaalisessa koneessa.
Ja olisi mukavaa, jos tämä olisi jonkinlainen Sharashkinin toimisto. Joten ei. Tunnettu yritys, jonka tuotteet luultavasti tunnet ja olet nähnyt kaikkien Lentojen ja Auchanien vastaavilla osastoilla.
Kiintolevyn loma-aikataulu
Suuri holdingyhtiö, jolla on kunnianhimoisia suunnitelmia valloittaa maailma, on jälleen ostanut pienen yrityksen tavoitteenaan liittää se megayhtiöänsä. Tämän tilan kaikissa osastoissa käyttäjät työskentelevät omissa tietokannoissaan, mutta kokoonpanolla on sama. Niinpä aloitimme pienen projektin uuden yksikön sisällyttämiseksi tähän järjestelmään.
Ensinnäkin on tarpeen ottaa käyttöön tuotanto- ja testitietokannat. Kehittäjä vastaanotti yhteystiedot, kirjautuu palvelimelle, näkee MS SQL:n asennettuna, 1C-palvelimen, näkee 2 loogista asemaa: aseman “C”, jonka kapasiteetti on 250 gigatavua, ja aseman “D”, jonka kapasiteetti on 1 teratavu. No, "C" on järjestelmä, "D" on data, kehittäjä päättää loogisesti ja ottaa käyttöön kaikki tietokannat. Tein jopa ylläpitosuunnitelmia, mukaan lukien varmuuskopion, varmuuden vuoksi (vaikka emme ole vastuussa tästä). Totta, varmuuskopiot lisättiin tähän kohtaan "D". Jatkossa se oli tarkoitus konfiguroida uudelleen johonkin erilliseen verkkoresurssiin.
Projekti käynnistyi, konsultit kouluttivat uuden järjestelmän työskentelyä, ylijäämät siirrettiin, pieniä parannuksia tehtiin ja käyttäjät aloittivat työskentelyn uudessa tietokannassa.
Kaikki meni hyvin, kunnes eräänä maanantaiaamuna havaittiin, että tietokantalevy puuttui. Palvelimella ei yksinkertaisesti ole D-kirjainta, ja se on siinä.
Lisätutkimukset paljastivat tämän: tämä "palvelin" oli itse asiassa paikallisen järjestelmänvalvojan työtietokone. Totta, sillä oli silti palvelinkäyttöjärjestelmä. Tämän järjestelmänvalvojan henkilökohtainen USB-asema oli kytketty palvelimeen. Ja niin järjestelmänvalvoja lähti lomalle ja otti ruuvinsa mukaansa tavoitteenaan pumpata siihen elokuvia matkaa varten.
Luojan kiitos, hän ei onnistunut poistamaan tietokantatiedostoja ja onnistui palauttamaan tuottavan tietokannan.
On huomionarvoista, että kaikki olivat yleensä tyytyväisiä USB-asemalla olevan järjestelmän suorituskykyyn. Kukaan ei valittanut 1C:n epätyydyttävästä suorituskyvystä. Vasta myöhemmin holding aloitti megaprojektin siirtää kaikki tietokannat yhdelle keskitetylle sivustolle superpalvelimilla, yli miljoonan ruplan tallennusjärjestelmillä, kehittyneillä hypervisoreilla ja sietämättömillä 1C-jarruilla kaikilla aloilla.
Mutta se on täysin eri tarina...
Lähde: will.com