Büyüleyici tahmin dünyasına dalmaya devam ediyoruz ... günlüklerle sorun giderme. İÇİNDE temel terimlerin anlamı üzerinde anlaştık ve tek gözle tek bir uygulama olarak Veeam'in genel yapısına baktık. Bunun görevi, günlük dosyalarının nasıl oluşturulduğunu, içlerinde ne tür bilgilerin görüntülendiğini ve neden göründükleri gibi göründüklerini anlamaktır.
Sizce bu "günlükler" nedir? Çoğu kişiye göre, herhangi bir uygulamanın günlüklerine, çoğu zaman arka bahçede bir yerlerde ot gibi büyüyen, ancak doğru anda birdenbire parlak bir zırh içinde ortaya çıkan ve herkesi kurtaran bir tür her şeye gücü yeten varlık rolü atanmalıdır. Yani, her bileşendeki en ufak hatalardan bireysel veritabanı işlemlerine kadar her şeyi içermelidirler. Ve böylece hatadan sonra, başka nasıl düzeltileceği hemen yazıldı. Ve tüm bunlar birkaç megabayta sığmalı, artık değil. Bu sadece metin! Metin dosyaları onlarca gigabayt alamaz, bir yerde duymuştum!
Yani günlükler
Gerçek dünyada günlükler yalnızca teşhis bilgilerinin bir arşividir. Ve orada neyin depolanacağı, depolama için bilgilerin nereden alınacağı ve bunun ne kadar ayrıntılı olması gerektiğine geliştiricilerin kendileri karar verir. Birisi ON / OFF seviyesinin kaydını tutarak minimalizm yolunu izliyor ve birisi ulaşabildiği her şeyi özenle tarıyor. Günlük Kaydı Düzeyini seçme yeteneğine sahip bir ara seçenek olmasına rağmen, ne kadar ayrıntılı bilgi depolamak istediğinizi ve ne kadar fazladan disk alanınız olduğunu kendiniz belirttiğinizde =) Bu arada, VBR'nin bu tür altı düzeyi vardır. Ve inanın bana, diskinizde boş alan bulunan en ayrıntılı günlük kaydıyla ne olduğunu görmek istemezsiniz.
İyi. Neyi kurtarmak istediğimizi kabaca anladık, ancak meşru bir soru ortaya çıkıyor: bu bilgiyi nereden alacağız? Tabii ki, iç süreçlerimizle kendimizi kaydetmemiz için olayların bir parçasını oluşturuyoruz. Ancak dış çevre ile bir etkileşim olduğunda ne yapmalı? Veeam, koltuk değnekleri ve bisiklet cehennemine kaymamak için zaten icat edilmiş buluşları icat etmeme eğilimindedir. Hazır bir API, yerleşik işlev, kitaplık vb. olduğunda, mekanizmalarımızı çitlemeye başlamadan önce hazır seçenekleri tercih edeceğiz. İkincisi de yeterli olmasına rağmen. Bu nedenle, günlükleri analiz ederken, aslan hata payının üçüncü taraf API'lerden, sistem çağrılarından ve diğer kitaplıklardan gelen mesajlara düştüğünü anlamak önemlidir. Bu durumda, VBR'nin rolü, bu hataları olduğu gibi günlük dosyalarına iletmektir. Ve kullanıcının asıl görevi, hangi satırın kimden olduğunu ve bu "kimin" neden sorumlu olduğunu anlamayı öğrenmektir. Bu nedenle, VBR günlüğündeki bir hata kodu sizi bir MSDN sayfasına götürürse, bu iyi ve doğrudur.
Daha önce anlaştığımız gibi: Veeam sözde SQL tabanlı bir uygulamadır. Bu, tüm ayarların, tüm bilgilerin ve genel olarak yalnızca normal işleyiş için gerekli olan her şeyin - her şeyin veritabanında saklandığı anlamına gelir. Dolayısıyla basit gerçek: günlüklerde olmayanlar büyük olasılıkla veritabanındadır. Ancak bu sihirli değnek de değildir: Bazı şeyler Veeam bileşenlerinin yerel günlüklerinde veya veri tabanında yer almaz. Bu nedenle, ana bilgisayar günlüklerini, yerel makinenin günlüklerini ve yedekleme ve geri yükleme işlemine dahil olan her şeyin günlüklerini nasıl inceleyeceğinizi öğrenmeniz gerekir. Ayrıca, gerekli bilgilerin hiçbir yerde bulunmadığı da olur. yol bu.
Bu tür API'lerin bazı örnekleri
Bu liste istisnai bir şekilde eksiksiz olmayı amaçlamadığından nihai gerçeği onda aramaya gerek yoktur. Amacı, yalnızca ürünlerimizde kullanılan en yaygın üçüncü taraf API'leri ve teknolojileri göstermektir.
İle başlayalım VMware.
Listede ilk olacak vSphere API'si. Kimlik doğrulama, hiyerarşiyi okuma, anlık görüntüler oluşturma ve silme, makineler hakkında bilgi isteme ve çok (çok) daha fazlası için kullanılır. Çözümün işlevselliği çok geniştir, bu nedenle sürüm için VMware vSphere API Reference'ı önerebilirim. и . Daha güncel sürümler için her şey Google'da aranır.
VIX API'si. Ayrı bir hipervizörün kara büyüsü . Ana bilgisayardaki dosyalarla ağ üzerinden bağlanmadan çalışmak için VMware API. Daha iyi bir iletişim kanalı olmayan bir makineye dosya koymanız gerektiğinde son çare seçeneği. Dosya büyükse ve ana bilgisayar yüklüyse bu acı ve ıstıraptır. Ancak burada kural, 56,6 Kb / s'nin bile 0 Kb / s'den daha iyi olduğu şeklinde çalışır. Hyper-V'de bu şeye PowerShell Direct adı verilir. Ama bu sadece daha önceydi
vSpehere Web Hizmetleri API'sı vSphere 6.0'dan başlayarak (yaklaşık olarak, bu API ilk kez 5.5 sürümünde kullanıma sunulduğundan beri) konuk makinelerle çalışmak için kullanılır ve neredeyse her yerde VIX'in yerini almıştır. Aslında bu, vSphere'i yönetmek için başka bir API'dir. Meraklısına okumasını tavsiye ederim Manuel.
VDDK (Sanal Disk Geliştirme Kiti). Bu bölümde kısmen ele alınan kütüphane . Sanal diskleri okumak için kullanılır. Bir zamanlar VIX'in bir parçasıydı, ancak zamanla ayrı bir ürüne taşındı. Ancak mirasçı olarak VIX ile aynı hata kodlarını kullanır. Ancak bazı nedenlerden dolayı SDK'nın kendisinde bu hataların açıklaması yoktur. Bu nedenle, ampirik olarak, diğer kodlardaki VDDK hatalarının yalnızca ikiliden ondalık koda bir çeviri olduğu bulundu. İki bölümden oluşur - ilk yarısı bağlam hakkında belgelenmemiş bilgiler, ikinci bölüm ise geleneksel VIX / VDDK hatalarıdır. Örneğin, şunu görürsek:
VDDK error: 21036749815809.Unknown error
Sonra bunu cesaretle hex'e çeviririz ve 132200000001'i elde ederiz. 132200'ün bilgi vermeyen başlangıcını atarız ve geri kalan bizim hata kodumuz olur (VDDK 1: Bilinmeyen hata). En sık görülen VDDK hataları hakkında, yakın zamanda ayrı bir .
şimdi bakalım Pencereler.
Burada bizim için en gerekli ve önemli olan her şey standartta bulunabilir. olay GörüntüleyiciAncak bir sorun var: uzun süredir devam eden bir geleneğe göre... Windows Hata metninin tamamını değil, yalnızca numarasını kaydeder. Örneğin, hata 5 "Erişim reddedildi", 1722 "RPC sunucusu kullanılamıyor" ve 10060 "Bağlantı zaman aşımına uğradı" anlamına gelir. Elbette, en sık karşılaşılanları hatırlamanız harika, peki ya daha önce hiç görmediğiniz hatalar?
Ve hayatın hiç bal gibi görünmemesi için hatalar da 0x8007 ön ekiyle onaltılık biçimde saklanır. Örneğin, 0x8007000e aslında 14, Bellek Dolu'dur. Bunun neden ve kimin için yapıldığı karanlığa bürünmüş bir muammadır. Ancak, hataların tam listesi ücretsiz olarak ve SMS olmadan indirilebilir. .
Bu arada, bazen sadece 0x8007 değil, başka önekler de vardır. Böylesine üzücü bir durumda, HRESULT'u ("sonuç tutamacı") anlamak için, daha derine inmeniz gerekir. geliştiriciler için. Sıradan hayatta bunu yapmanızı tavsiye etmem ama aniden duvara yaslanırsanız veya sadece merak ederseniz, artık ne yapacağınızı biliyorsunuz.
Ancak Microsoft'taki yoldaşlar bize biraz acıdı ve dünyaya bir fayda gösterdi. . Google kullanmadan hata kodlarını insana çevirebilen küçük bir konsol saadeti bu. Bu şekilde çalışır.
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"Meşru bir soru ortaya çıkıyor: neden şifre çözmeyi hemen günlüklere yazmıyoruz, ama bu gizemli kodları bırakıyoruz? Cevap, üçüncü taraf uygulamalarındadır. Bazı WinAPI çağrılarını kendinize çektiğinizde, bunun cevabını deşifre etmek zor değil çünkü bunun için özel bir WinAPI çağrısı bile var. Ancak daha önce de belirtildiği gibi, bize yalnızca yanıtlarda gelen her şey günlüklerimize giriyor. Ve burada, şifresini çözmek için, kişinin bu bilinç akışını sürekli izlemesi, ondan Windows hataları olan parçaları çıkarması, şifresini çözmesi ve geri yapıştırması gerekir. Dürüst olalım, en heyecan verici aktivite değil.
Windows Dosya Yönetimi API'si dosyalarla çalışırken mümkün olan her şekilde kullanılır. Dosya oluşturma, silme, yazmaya açma, niteliklerle çalışma vb.
Yukarıda belirtilen PowerShell Doğrudan Hyper-V dünyasında VIX API'sinin bir benzeri olarak. Ne yazık ki, o kadar esnek değil: işlevsellik üzerinde çok fazla kısıtlama var, ev sahibinin her sürümüyle ve tüm konuklarla çalışmıyor.
RPC (Uzaktan Prosedür Çağrısı) WIndows ile çalışmış ve RPC ile ilgili hataları görmemiş tek bir kişi olduğunu sanmıyorum. Popüler yanlış kanıya rağmen, bu tek bir protokol değil, bir dizi parametreyi karşılayan herhangi bir istemci-sunucu protokolüdür. Ancak günlüklerimizde bir RPC hatası varsa, bu hata %90 oranında DCOM'un (Dağıtılmış Bileşen Nesne Modeli) bir parçası olan Microsoft RPC'den kaynaklanacaktır. İnternette bu konuyla ilgili çok sayıda belge bulabilirsiniz, ancak bunların aslan payı oldukça eskidir. Ancak konuyu incelemek için şiddetli bir istek varsa, o zaman makaleler önerebilirim , ve uzun liste .
Günlüklerimizdeki RPC hatalarının ana nedenleri, VBR bileşenleri (örneğin sunucu > proxy) arasındaki başarısız iletişim girişimleridir ve çoğunlukla iletişim sorunlarından kaynaklanır.
Tüm üstler arasında en üstteki, RPC sunucusu kullanılamıyor (1722) hatasıdır. Basit bir ifadeyle, istemci sunucuyla bağlantı kuramadı. Nasıl ve neden - tek bir cevap yoktur, ancak genellikle kimlik doğrulama veya 135 numaralı bağlantı noktasına ağ erişimi ile ilgili bir sorundur. İkincisi, dinamik bağlantı noktası ataması olan altyapılar için tipiktir. Hatta bu konu hakkında . Ve Microsoft'un sahip olduğu başarısızlığın nedenini bulmak için.
İkinci en yaygın hata: Bitiş noktası eşleştiricisinden (1753) başka uç nokta yok. RPC istemcisi veya sunucusu kendisine bir bağlantı noktası atayamadı. Genellikle, sunucu (bizim durumumuzda konuk makine), sonlanan dar bir aralıktaki bağlantı noktalarını dinamik olarak tahsis edecek şekilde yapılandırıldığında ortaya çıkar. İstemci tarafından (bizim durumumuzda VBR sunucusu) oturum açarsanız bu, VeeamVssAgent'ımızın başlamadığı veya bir RPC arayüzü olarak kaydedilmediği anlamına gelir. bu konu da var .
İlk 3 RPC hatasını tamamlamak için, RPC işlev çağrısının başarısız olduğunu hatırlayalım (1726). Bağlantı kurulduysa görünür, ancak RPC istekleri işlenmez. Örneğin, VSS'nin durumu hakkında bilgi talep ediyoruz (şu anda orada aniden bir gölge mayın yapılıyor ve biz tırmanmaya çalışıyoruz) ve bize yanıt olarak susturup görmezden geliyoruz.
Windows Bant Yedekleme API'si teyp kitaplıkları veya sürücülerle çalışmak için gereklidir. Başta da belirttiğim gibi: Kendi sürücülerimizi yazıp sonra her cihazın desteğiyle sıkıntı çekmekten zevk almıyoruz. Bu nedenle, vim'in kendine ait herhangi bir sürücüsü yoktur. Tümü, desteği donanım satıcıları tarafından uygulanan standart bir API aracılığıyla. Çok daha mantıklı, değil mi?
SMB / CIFS Herkes alışkanlık gereği bunları birlikte yazıyor, ancak herkes CIFS'in (Ortak İnternet Dosya Sistemi) aslında SMB'nin (Sunucu Mesaj Bloğu) tescilli bir sürümü olduğunu hatırlamıyor. Dolayısıyla bu kavramları genelleştirmenin bir sakıncası yok. Öte yandan Samba ise... LinuxBu bir Unix uygulaması ve kendine özgü özellikleri var, ama konudan sapıyorum. Burada önemli olan, Veeam bir UNC yoluna (sunucu dizini) bir şey yazmayı istediğinde, sunucunun paylaşılan sürücüye yazmak için mup ve mrxsmb dahil olmak üzere bir dosya sistemi sürücüleri hiyerarşisi kullanmasıdır. Sonuç olarak, bu sürücüler de hatalar üretecektir.
onsuz yapamam Winsock API'siAğ üzerinden bir işlem yapılması gerekiyorsa, VBR bu işlemi gerçekleştirir. Windows Socket API, genellikle Winsock olarak bilinir. Dolayısıyla, logda bir IP:Port bağlantısı görürsek, bu bağlantının bu şekilde olduğunu anlarız. Resmi dokümantasyonda olası bağlantı türlerinin iyi bir listesi bulunmaktadır. .
Yukarıda belirtilen WMI (Windows Yönetim Enstrümantasyonu, dünyadaki her şeyi ve herkesi yönetmek için kullanılan bir tür her şeye kadir API'dir. WindowsÖrneğin, Hyper-V ile çalışırken, sunucuya yapılan neredeyse tüm istekler onun üzerinden işlenir. Kısacası, kesinlikle vazgeçilmez ve çok güçlüdür. Dahili WBEMtest.exe aracı, sorunun ne olduğunu anlamaya çalışırken çok yardımcı olur.
Ve listenin sonuncusu, ama kesinlikle en önemsizi değil - VSS (Birim Gölge Depolama). Konu, hakkında çok fazla belge yazıldığı kadar tükenmez ve gizemlidir. Gölge Kopya en basit şekilde, özünde öyle olan özel bir anlık görüntü türü olarak anlaşılır. Onun sayesinde VMware'de uygulama tutarlı yedeklemeler ve Hyper-V'de neredeyse her şey yapabilirsiniz. VSS'yi biraz sıkıştırarak ayrı bir makale yapmayı planlıyorum ama şimdilik okumaya çalışabilirsiniz . Sadece dikkatli ol, çünkü. VSS'yi bir anda anlamaya çalışmak beyin hasarına yol açabilir.
Bu konuda belki durabiliriz. Tamamlanan en temel şeyleri açıklama görevini düşünüyorum, bu nedenle bir sonraki bölümde günlüklere zaten bakacağız. Ancak herhangi bir sorunuz varsa, yorumlarda onlara sormaktan çekinmeyin.
Kaynak: habr.com
