MPIO yolu arızası sırasında aşağıdaki gibi uyarıları gösteren çok yollu IO yapılandırılmış sunucu 2012 blade'im var:
Disk 7 için 0 mantıksal blok adresindeki GÇ işlemi yeniden denenmiştir.
Uyarının gerçekleşmesine neyin neden olduğunu biliyorum, bu yüzden sebebi aramıyorum ama bu mesaj aslında ne anlama geliyor?
Bu IO bir yazma işlemi ise sunucu gerçekten yazmaya çalıştığı verileri kaybetti mi?
Bu uyarı mesajının anlamını tutabileceğiniz her türlü ışık için teşekkür ederiz.
Yanıtlar:
Hayır, verilerin kaybolduğu anlamına gelmez. Bu sadece, IO Sistemi'nin tamamlanmasını beklerken IRP'nin (IO İstek Paketi) zaman aşımına uğradığı ve bu nedenle tekrar denendiği anlamına gelir. Bir iş parçacığı herhangi bir GÇ işlemine başladığında, GÇ yöneticisi, sistemden geçerken işlemi temsil etmek için bir IRP oluşturur.
IRP başlangıç durumunda bir arabellek / yan yana listede saklanır, böylece ilk kez başarısız olursa tekrar denenebilir. Bu işlem, herhangi bir işlem sisteminden bekleyeceğiniz atomiteyi sağlar, böylece diskinize yazılmış bir sürü bozuk veya eksik veri almayacağınıza daha fazla güvenebiliriz.
Bu olay, bir MPIO arızası durumunda mükemmel anlam ifade eder. Windows'un SAN depolama biriminden bir şeyler okuyup yazmaya gittiğini söyleyin. İstek gönderilir ve aynı anda, SAN'dan gelen kablolardan birini kestim. Bu istek hiçbir zaman tamamlanmayacak ve böylece Windows isteği yeniden deneyecek, ancak bu kez istek diğer yolu izleyecektir.
Bu olaylar, diskler aşırı yüklendiğinde veya çok yavaş olduğunda da ortaya çıkar. Bu iletilerin zamanlanmış yedeklemelerle çakıştığını fark edebilirsiniz. Disk yavaş ve meşgul olabilir ve bazı rasgele IRP zaman aşımına uğradı ve tekrar denemek zorunda kaldı. IRP, bir servis kesintisine veya ertelenmiş bir prosedür çağrısına ya da her neyse sıkışmış olabilir.
Yığında bir sürü IO filtre sürücüsü olduğunu görebiliyordum.
Bu davranış, Windows'un önceki sürümlerinde bu şekilde gerçekleşmedi, yalnızca Microsoft bu olayları Win8 / Server 2012'de görmeye başladı.
Düzenleme: Çekirdek hata ayıklayıcısına sahip bir iş parçacığının seçkin IRP'lerini bulabilirsiniz:, kd> !irp 1a2b3c4ddaha önce bu adresi kd> !process 8f7d6c4a, bu işlemle ilişkilendirilen iş parçacıklarıyla ilişkili tüm IRP'leri listeleyen bir komut vererek bulabilirsiniz. kd> !process 0 0Çalışan tüm işlemleri listelemek için.
! İrp komutunu kullanarak bir IRP hakkındaki bilgileri listeledikten sonra, hangi sürücünün IRP'yi en son kullandığını kolayca görebilirsiniz, çünkü >listede onu işaret eder. Ardından, bu sürücünün o IRP ile ne yaptığı hakkında daha fazla bilgi edinmek kd> !devobj 1a2b3c4d5e6fiçin, cihaz nesnesinin asıl adresi olan bir yerde yapın.
Sonra sahip olduğunuz kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATAPrivateFdoData yapısının adresini kullanarak yapın.
Artık PrivateFdoData'dan aldığınız AllTransferPacketsList veri yapısını atmaya hazırsınız.
Fikir şu ki, en son göründüğünde IRP ile hangi sürücünün ne yaptığını izliyorsunuz. IRP çok uzun süre AWOL ise, zaman aşımına uğrar ve en baştan denenir. Buna bir çok şey neden olabilir ... başıboş bir kozmik ışın bile. Ancak önemli olan, işlemin en baştan yeniden deneneceği ve IO yöneticisi söyleyene kadar tam olarak kabul edilmeyeceğidir.
Oh, ayrıca tamamen farklı bir solucan kutusu olan, dişi-aşındırıcı bir IO var . :)
Bu konuyla ilgili daha geniş bilgi için, son derece tavsiye bölüm 8, Mark Russinovich, Margosis, vd Windows Içselleri 6 baskısının I / O sistemi,.
** Düzenleme: ** Sonunda bu hata için resmi KB buldum: http://support.microsoft.com/kb/2819485/EN-US
IO işlemi Windows pes edene kadar dakikada bir kez 8 kez tekrar denenmelidir.
Düzenleme: Söz verildiği gibi: http://blogs.msdn.com/b/ntdebugging/archive/2013/04/30/interpreting-event-153-errors.aspx
Hayır, farklı bir mesaj olacaktı ve (umarım) uygulama katmanlarından biri, verileri başarıyla kaydedemezse bir istisna atar.
Windows Server 2012'den önce (veya Windows Server 2008 R2'de ise 2819485 düzeltmesi), bu zaman aşımına uğradığında sistem sessizce yeniden dener. Mesajın amacı, bu olaylar hakkında görünürlüğü arttırmaktır. Bir kapasite sorunu veya sürücü hatası gösterebilirler ve iSCSI durumunda, diğer işletim sistemi hataları gecikmeye bağlı olabilir.
Harici (doğrudan bağlı olmayan) depolama durumunda, geçmişte bazı satıcılar zaman aşımı değerini, örneğin 60 saniyeye çıkardılar. Bununla birlikte, iSCSI başlatıcısı gibi daha yüksek katman bileşenlerinin varsayılan deneme sayısı göz önüne alındığında, bu, sistem yerine çalışma başlamadan önce birkaç dakika geçebileceği anlamına gelebilir. Bu açıkçası en düşük davranış olacaktır.
Daha fazla bilgi:
SCSI Miniport Sürücüler için Kayıt Defteri Girdileri
http://msdn.microsoft.com/en-us/library/windows/hardware/ff563970%28v=vs.85%29.aspx
Microsoft, storport.sys işlemleri için eşiği belirleme özelliği sağlayan bir güncelleme yayımladı.
Bu güncelleştirmeyi yükledikten sonra, G / Ç depolama için gecikme süresi bir eşik değere eşit veya ondan büyük olduğunda bir olay günlüğe kaydedebilirsiniz. Eşik değeri kullanıcı tarafından ayarlanabilir. Bu işlem Adaptör Sürücüsü seviyesinde gerçekleştirilir, böylece SAN'da bir performans sorunu olup olmadığını görebilirsiniz. Ardından, sorunu gidermek için bir depolama satıcısına başvurabilirsiniz.
Not: Bu güncelleştirme, Windows 7 ve Windows Server 2008 R2'de sağlanan işlevselliği geri yükler. İşlevsellik etkinleştirildiğinde, eşik değeri 100 nanosaniye (0.0001 milisaniye) cinsinden ölçülür. Ayrıca, olaya aşağıdaki değerler kaydedilir:
BuildIoDuration : Miniport bu istek için inşa I / O fonksiyonu geçirdiği zamanın uzunluğu StartIoDuration sürenin uzunluğu miniport bu istek için başlangıç G / Ç fonksiyonunda harcamış olduğu: DataTransferLength : Boyutu transferi bayt
Storport.sys sürücüsünün Windows Server 2012'deki günlük tutma özelliklerini geliştiren güncelleştirme
http://support.microsoft.com/kb/2819476
Windows 8 ve Windows Server 2012 toplu güncelleştirmesi: Nisan 2013
http://support.microsoft.com/kb/2822241
Geç bir posta olabilir, ancak VSS ile sonuçlanabileceğini öğrendim. Veeam çalıştıran ancak windows server'ı kapatmayı unutmuş (disk kaldırılmış) bir müşterimiz vardı.
Geri durdu ve hiçbir hata yapmadı.