Em binavbûna xwe di cîhana balkêş a texmînkirinê de didomînin ... çareserkirina pirsgirêkan bi têketin. LI me li ser wateya şertên bingehîn li hev kir û bi yek çavî li avahiya giştî ya Veeam wekî serîlêdanek yekane mêze kir. Erka vê yekê ev e ku meriv fêr bibe ka pelên têketinê çawa têne çêkirin, çi celeb agahdarî di wan de têne xuyang kirin û çima ew bi awayê ku xuya dikin xuya dikin.
Bi dîtina we ev "qeyd" çi ne? Li gorî piran, têketinên her serîlêdanê divê rola celebek sazûmanek domdar were destnîşan kirin ku pir caran li deverek li hewşa paşîn şîn dibe, lê di wextê rast de ji nedîtî ve di zirxên ronî de xuya dike û her kesî xilas dike. Ango, divê ew her tiştî hebin, ji xeletiyên herî piçûk di her pêkhateyê de heya danûstendinên databasên kesane. Û ji ber vê yekê ku piştî xeletiyê tavilê hate nivîsandin ka meriv wê çawa rast bike. Û ev hemî divê di çend megabytes de, ne bêtir. Ew tenê nivîsek e! Pelên nivîsê nikarin bi dehan gigabaytan bigirin, min ew li cîhek bihîst!
Ji ber vê yekê têketin
Di cîhana rastîn de, têketin tenê arşîvek agahdariya tespîtkirinê ne. Û çi li wir hilanîn, li ku derê agahdariya ji bo hilanînê bistînin û ew çiqas hûrgulî be, biryarê ji pêşdebiran re ye. Kesek rêça mînîmalîzmê dişopîne bi tomarkirina asta ON / OFF, û kesek bi xîret her tiştê ku ew dikare bigihîje radike. Her çend di heman demê de vebijarkek navîn jî heye ku jêhatîbûna hilbijartina bi navê Asta Têketinê heye, gava ku hûn bixwe diyar dikin ka hûn çiqas agahdariya hûrgulî dixwazin hilînin û çiqas cîhê dîskê we heye =) VBR şeş astên weha hene, bi awayê. Û, ji min bawer bikin, hûn naxwazin bibînin ka bi têketina herî berfireh a bi cîhê belaş li ser dîska we re çi diqewime.
Baş. Me bi qasî fêm kir ku em dixwazin çi xilas bikin, lê pirsek rewa derdikeve holê: meriv vê agahiyê ji ku bigire? Bê guman, em beşek ji bûyeran pêk tînin ji bo ku xwe bi pêvajoyên xwe yên hundurîn ve bişopînin. Lê gava ku têkiliyek bi hawîrdora derve re hebe meriv çi bike? Ji bo ku nekeve nav dojeheke kulm û bisiklêtan, Veeam meyla îcadên ku berê hatine îcadkirin îcad nake. Kengê ku API-ya amadekirî, fonksiyonek çêkirî, pirtûkxane, hwd. hebe, em ê berê xwe bidin vebijarkên amade berî ku dest bi dorpêçkirina kêşeyên xwe bikin. Her çend ya dawî jî bes e. Ji ber vê yekê, dema ku têketin analîz dikin, girîng e ku meriv fêm bike ku para şêrê xeletiyan dikeve ser peyamên ji API-yên sêyemîn, bangên pergalê û pirtûkxaneyên din. Di vê rewşê de, rola VBR ji şandina van xeletiyan berbi pelên têketinê yên wekî xwe tê. Û peywira sereke ya bikarhêner ev e ku fêr bibe ku fêm bike ka kîjan rêz ji kê ye, û ev "kî" berpirsiyar e. Ji ber vê yekê heke kodek xeletiyek ji têketina VBR we bigihîne rûpelek MSDN, ew baş û rast e.
Wekî ku me berê li hev kir: Veeam bi navê serîlêdana SQL-ê ye. Ev tê vê wateyê ku hemî mîheng, hemî agahdarî û bi gelemperî her tiştê ku tenê ji bo xebata normal hewce ye - her tişt di databasa xwe de tête hilanîn. Ji ber vê yekê rastiya hêsan: tiştê ku ne di têketinê de ye bi îhtîmalek mezin di databasê de ye. Lê ev ne guleyek zîv e jî: hin tişt ne di têketinên herêmî yên pêkhateyên Veeam de ne, ne jî di databasa wê de ne. Ji ber vê yekê, hûn hewce ne ku fêr bibin ka meriv çawa têketinên mêvandar, têketinên makîneya herêmî û têketinên her tiştê ku di pêvajoya hilanînê û sererastkirinê de têkildar e, dixwîne. Û her weha diqewime ku agahdariya pêwîst li her derê tune. Ew rê ye.
Hin mînakên API-yên weha
Armanca vê navnîşê ew e ku bêkêmasî bêkêmasî be, ji ber vê yekê ne hewce ye ku li rastiya dawîn di wê de bigerin. Armanca wê tenê ew e ku API-yên partiya sêyemîn û teknolojiyên herî gelemperî yên ku di hilberên me de têne bikar anîn nîşan bide.
Ka em dest pê bikin VMware.
Di lîsteyê de yekem dê bibe vSphere API. Ji bo erêkirin, xwendina hiyerarşiyê, çêkirin û jêbirina wêneyan, daxwazkirina agahdariya li ser makîneyan, û pir (pir) bêtir tê bikar anîn. Karbidestiya çareseriyê pir berfireh e, ji ber vê yekê ez dikarim VMware vSphere API Reference ji bo guhertoyê pêşniyar bikim и . Ji bo guhertoyên bêtir niha, her tişt tenê google tête kirin.
VIX API. Magic reş ya hypervisor, ji bo ku cuda heye . VMware API ji bo xebitandina pelên li ser mêvandar bêyî girêdana bi wan re li ser torê. Guhertoyek çareya paşîn dema ku hûn hewce ne ku pelek bixin nav makîneyek ku kanalek pêwendiyê jê çêtir tune. Heger pel mezin be û mêvandar were barkirin êş û jan e. Lê li vir qaîdeyek dixebite ku 56,6 Kb / s jî ji 0 Kb / s çêtir e. Di Hyper-V de, ev tişt jê re PowerShell Direct tê gotin. Lê ew tenê berê bû
vSpehere Xizmetên Web API Ji vSphere 6.0-ê dest pê dike (nêzîkî, ji ber ku ev API yekem car li ser guhertoya 5.5-ê hate destnîşan kirin) ew ji bo xebitandina makîneyên mêvanan tê bikar anîn û hema hema li her deverê VIX cîh girtiye. Bi rastî, ev API-ya din a ji bo birêvebirina vSphere ye. Ji bo kesên eleqedar, ez pêşniyar dikim ku bixwînin destî.
VDDK (Kiteya Pêşveçûna Dîska Virtual). Pirtûkxane, ku di vê yekê de bi qismî hate nîqaş kirin . Ji bo xwendina dîskên virtual tê bikar anîn. Carekê ew beşek ji VIX bû, lê bi demê re ew di hilberek cûda de hate veguheztin. Lê wekî mîrasek, ew heman kodên xeletiyê wekî VIX bikar tîne. Lê ji ber hin sedeman, di SDK bi xwe de ravekirina van xeletiyan tune. Ji ber vê yekê, bi ezmûnî hate dîtin ku xeletiyên VDDK yên bi kodên din re tenê wergerek ji koda binary bo dehek e. Ew ji du beşan pêk tê - nîvê yekem di derheqê çarçoveyê de agahdariya nebelge ye, û beşa duyemîn xeletiyên kevneşopî yên VIX / VDDK e. Ji bo nimûne, eger em bibînin:
VDDK error: 21036749815809.Unknown error
Dûv re em bi wêrekî vê vediguhezînin hex û 132200000001 distînin. Em bi hêsanî destpêka 132200-a neagahdar berdidin, û ya mayî dê koda xeletiya me be (VDDK 1: Çewtiya nenas). Di derbarê xeletiyên VDDK-ê yên herî pir caran de, di van demên dawî de veqetandî hebû .
Niha em lê binêrin Windows.
Li vir, her tiştê ku ji bo me herî hewce û girîng e dikare di standardê de were dîtin Event Viewer. Lê yek girtinek heye: li gorî kevneşopiyek dirêj, Windows ne nivîsa tevahî ya xeletiyê, lê tenê jimara wê tomar dike. Mînakî, xeletiya 5 "Gihîn hate red kirin", û 1722 "Pêşkêşkara RPC ne berdest e", û 10060 "Dema girêdanê qediya" ye. Bê guman, ger hûn yên herî navdar bi bîr bînin pir xweş e, lê yên ku heya niha nehatine dîtin çi dikin?
Û ji bo ku jiyan qet mîna hingiv xuya neke, xeletî jî di forma hexadecimal de, bi pêşgira 0x8007, têne tomar kirin. Mînakî, 0x8007000e bi rastî 14 e, Ji Bîrê ne. Çima û ji bo kê ev hat kirin nepeniyek e ku di tariyê de ye. Lêbelê, navnîşek bêkêmasî ya xeletiyan dikare belaş û bêyî SMS-ê were dakêşandin .
Bi awayê, carinan pêşgirên din hene, ne tenê 0x8007. Di rewşek wusa xemgîn de, ji bo ku hûn HRESULT ("destpêka encamê") fêm bikin, hûn hewce ne ku hûn hîn kûrtir têbikoşin. ji bo pêşdebiran. Di jiyana asayî de, ez ji we re şîret nakim ku hûn wiya bikin, lê heke we ji nişkê ve li dîwarê xwe davêje an tenê meraq dike, naha hûn dizanin ka çi bikin.
Lê rêhevalên Microsoft-ê hinekî li me rehm kirin û bikêrhatîyek nîşanî cîhanê dan . Ev perçeyek piçûk a bextewariya konsolê ye ku dikare kodên xeletiyê bêyî karanîna Google wergerîne mirovan. Bi vî rengî dixebite.
C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"Pirsek rewa derdikeve holê: çima em tavilê deşîfrekirinê li têketinê nanivîsin, lê van kodên nepenî bihêlin? Bersiv di serîlêdanên partiya sêyemîn de ye. Dema ku hûn hin gazîkirina WinAPI-ê ji xwe re dikişînin, ne dijwar e ku hûn bersiva wê deşîfre bikin, ji ber ku ji bo vê yekê bangek WinAPI-ya taybetî jî heye. Lê wekî ku berê jî behs kir, her tiştê ku tenê di bersivê de ji me re tê, dikeve têketinên me. Û li vir, ji bo deşîfrekirina wê, pêdivî ye ku meriv bi domdarî çavdêriya vê herikîna hişmendiyê bike, perçeyên xeletiyên Windows-ê jê derxe, wan deşîfre bike û wan paşve bişopîne. Werin em rast bin, ne çalakiya herî balkêş.
API Rêveberiya Pelê ya Windows dema ku bi pelan re dixebitin bi her awayî tê bikar anîn. Afirandina pelan, jêbirin, vekirina ji bo nivîsandinê, xebata bi taybetmendiyan û hwd û hwd.
li jor behs kirin PowerShell Direct wekî analogek VIX API di cîhana Hyper-V de. Mixabin, ne ew qas maqûl: gelek qedexeyên li ser fonksiyonê, ew bi her guhertoya mêvandar re û ne bi hemî mêvanan re dixebite.
RPC (Banga Pêvajoya Dûr) Ez nafikirim ku kesek bi WIndows-ê re xebitîbe ku xeletiyên girêdayî RPC-ê nedîtibe. Tevî têgihîştina xeletî ya populer, ev ne protokolek yekane, lê her protokolek xerîdar-server e ku çend pîvanan têr dike. Lêbelê, heke di têketinên me de xeletiyek RPC hebe, 90% ji dema ku ew ê xeletiyek ji Microsoft RPC be, ku beşek ji DCOM (Modela Objekta Pêkhateya Dabeşkirî) ye. Hûn dikarin gelek belgeyên li ser vê mijarê li ser torê bibînin, lê para şêrê wê pir kevnar e. Lê heke xwestekek tûj a xwendina mijarê hebe, wê hingê ez dikarim gotaran pêşniyar bikim , û lîsteya dirêj .
Sedemên sereke yên xeletiyên RPC-ê yên di têketinên me de hewildanên têkçûyî yên ragihandina di navbera pêkhateyên VBR de (mînak, server > proxy) û bi gelemperî ji ber pirsgirêkên ragihandinê ne.
Di nav hemî topên jorîn de xeletî ye Pêşkêşkara RPC ne berdest e (1722). Bi gotinên hêsan, xerîdar nikaribû bi serverê re têkiliyek saz bike. Çawa û çima - bersivek yekane tune, lê bi gelemperî ew pirsgirêkek rastrastkirinê an bi gihîştina torê ya porta 135-ê re pirsgirêkek e. Ya paşîn ji bo binesaziyên bi peywirdarkirina porta dînamîkî re tîpîk e. Di vê mijarê de jî heye . Û Microsoft heye ji bo dîtina sedema têkçûnê.
Çewtiya herî populer a duyemîn: Ji nexşerêya xala dawîn (1753) bêtir xalên dawî tune. Xerîdar an servera RPC nekariye ji xwe re portek destnîşan bike. Bi gelemperî dema ku server (di rewşa me de, makîneya mêvan) hate mîheng kirin ku bi dînamîk benderan ji navçeyek teng a ku qediyaye veqetîne. Û heke hûn ji hêla xerîdar ve têkevinê (di doza me de, servera VBR), ev tê vê wateyê ku VeeamVssAgent me an dest pê nekir an jî wekî navgînek RPC nehat tomar kirin. Di vê mijarê de jî heye .
Welê, ji bo temamkirina Top 3 xeletiyên RPC, em bînin bîra xwe ku banga fonksiyona RPC têk çû (1726). Ger girêdan hatibe damezrandin xuya dike, lê daxwazên RPC nayên pêvajo kirin. Mînakî, em agahdariya li ser rewşa VSS-ê daxwaz dikin (ji nişka ve li wir kaniyek siyê tê çêkirin, û em hewl didin ku hilkişin), û di bersiva me de, bêdeng û paşguh bikin.
Windows Tape Backup API hewce ye ku bi pirtûkxaneyên tape an ajokeran re bixebite. Wekî ku min di destpêkê de behs kir: kêfa me ji nivîsandina ajokarên xwe û dûv re jî bi piştgiriya her amûrekê re tune ye. Ji ber vê yekê, vim ajokerên xwe tune. Hemî bi navgîniya API-yek standard, ku piştgiriya wê ji hêla firoşkarên hardware bixwe ve tê bicîh kirin. Ji ber vê yekê pir maqûltir, rast?
SMB / CIFS Ji adetê, her kes wan li kêleka hev dinivîse, her çend her kes ji bîr nake ku CIFS (Pergala Pelên Înternetê ya Hevpar) tenê guhertoyek taybet a SMB (Bloka Peyama Server) ye. Ji ber vê yekê di giştîkirina van têgehan de tiştekî şaş nîne. Samba jixwe pêkanînek LinuxUnix-ê ye, û taybetmendiyên wê hene, lê ez dûr dibim. Li vir çi girîng e: gava Veeam dipirse ku tiştek li ser riya UNC-ê (rêvebera pêşkêşkerê) binivîsîne, server hiyerarşiya ajokarên pergala pelan, di nav de mup û mrxsmb, bikar tîne da ku li topê binivîsîne. Li gorî vê yekê, ev ajokar dê xeletiyan jî çêbikin.
Nikare bê Winsock API. Ger tiştek hewce bike ku li ser torê were kirin, VBR bi navgîniya Windows Socket API-ya ku bi gelemperî wekî Winsock tê zanîn dixebite. Ji ber vê yekê heke em di têketinê de komek IP:Port bibînin, ev ew e. Belgeya fermî navnîşek baş a gengaz heye .
li jor behs kirin WMI (Windows Management Instrumentation) celebek API-ya hêzdar e ku ji bo birêvebirina her tişt û her kesê li cîhana Windows-ê ye. Mînakî, dema ku bi Hyper-V re dixebitin, hema hema hemî daxwazên mêvandar jê re derbas dibin. Bi gotinekê, tişt bi îmkanên xwe ve bê guhêrbar e û pir bi hêz e. Di hewildanek ji bo ku hûn fêr bibin ka li ku û çi şikestî ye, amûra çêkirî ya WBEMtest.exe pir arîkar dike.
Û di lîsteyê de dawîn, lê ji hêla girîngiya herî kêm - VSS (Volume Shadow Storage). Mijar bi qasî ku tê de belgename hatine nivîsandin jî bêdawî û nepenî ye. Shadow Copy bi hêsanî wekî celebek taybetî ya wêneyê tê fêm kirin, ku di eslê xwe de ew e. Spas ji wî re, hûn dikarin di VMware-ê de, û hema hema her tiştî di Hyper-V de paşvekêşana serîlêdanê-hevdeng çêbikin. Planên min hene ku ez gotarek veqetandî bi hin hûrgulî li ser VSS-ê çêkim, lê heya niha hûn dikarin biceribînin ku bixwînin . Tenê hişyar bimînin, ji ber ku. hewldana fêmkirina VSS-ê bi lez dikare bibe sedema birîna mêjî.
Li ser vê, dibe ku, em dikarin bisekinin. Ez peywira ravekirina tiştên herî bingehîn temam dibînim, ji ber vê yekê di beşa pêş de em ê berê xwe bidin qeydan. Lê heke pirsên we hebin, di şîroveyan de ji wan bipirsin.
Source: www.habr.com