VMAX, PowerMax: IBMi ana bilgisayar platformu için kesintiye yol açmayan geçiş
Summary: Dell VMAX ve PowerMax kurumsal depolama platformu aileleri, iş açısından kritik ana bilgisayar sistemlerini, uygulama kapalı kalma süresi olmadan yeni depolama dizilerine geçirmek için depolama tabanlı Kesintiye Neden Olmayan Geçişleri (NDM) destekler. PowerMaxOS 5978.444.444 kod ailesinin kullanıma sunulmasının ardından IBMi ana bilgisayar platformu için NDM desteği eklenmiştir. 1. NOT: Dell'in yerel STM yazılım araç setini de (IBMi için SRDF/TimeFinder Manager) kullanan IBMi sistemlerinde, NDM işleminin (isteğe bağlı) son adımı geçirilen aygıtların aygıt kimliği sıfırlaması (kimlik sahtekarlığını giderme) işlemi tamamlandığında dikkat edilmesi gereken bazı ek hususlar vardır. Kimlik sıfırlama işlemini gerçekleştirmeden önce aşağıda verilen talimatları okuyun! 2. NOT: "Unspoof" işlemi olarak da belirtilen cihaz kimliği sıfırlamasının, unspoof'tan sonraki ilk program yükleme (IPL) aşaması için etkileri vardır. Aşağıda daha fazla ayrıntı okuyun. ...
Instructions
Destek Ortamı:
IBMi için NDM, PowerMaxOS un 5978.444.444 ya da sonraki bir sürümünü çalıştıran VMAX ya da PowerMax dizilerine bağlı, desteklenen IBMi ana bilgisayar sistemleri için kullanılabilir.
Bu, IBM Power Server platformu Power6 ya da sonraki sürümleri üzerinde çalışan ve IBMi işletim sistemi sürümü i6.1.1 ya da sonraki sürümleri çalıştıran IBMi Mantıksal bölümleri (LPAR' ler) içindir. VMAX ya da PowerMax genel e-Lab destek matrisi, ana bilgisayar veri yolu bağdaştırıcıları (HBA'lar) olarak da bilinen desteklenen Fibre Channel (FC) IBMi G/Ç Adaptörlerinin (IOA'lar) ayrıntılarını sağlar ve listeler. NDM, IBMi, IBM Sanal G/Ç Sunucusu'nun (VIOS) atanmış sanal G/Ç kaynakları olan bir istemci LPAR'si olduğunda da desteklenir. IBM VIOS/VFC (NPIV) özelliğiyle, sanal FC adaptörleri (vFC' ler), desteklenen SAN anahtarları kullanılarak depolama dizisine bağlanmak için istemci LPAR'larına atanır.
vFC'ler, ana bilgisayar disk bağlantısı için bir geçiş görevi görür; Ana bilgisayar tarafında bu tamamen şeffaftır ve depolama dizisinde desteklenen tüm özellikler bu sanallaştırılmış adaptör kurulumunda da kullanılabilir.
Arka plan ve Üst düzey geçiş senaryosu:
Symmetrix Remote Data Facility (SRDF), 1990'ların başında Dell Kurumsal Depolama dizileri için bir Olağanüstü Durum Kurtarma (DR) çoğaltma teknolojisi olarak geliştirilmiştir. Ayrıca, bir diziden başka bir diziye depolama tabanlı geçişler gerçekleştirmek için de yıllardır kullanılır. Yani, yeni bir depolama dizisi uygulayarak bir teknoloji yenilemesi gerçekleştirirken ESKİ ve YENİ dizileri "arka arkaya" bağlar ve veri birimlerini kopyalar. Birimlerin veya Mantıksal Birimlerin (LUN'lar) SRDF kopyalama işlemi, bağlı ana bilgisayar sistemleri için şeffaf olsa da, geleneksel olarak, kaynak birimlerden (R1'ler) kopyalama işlemi tamamlandığında her zaman kısa bir çevrimdışı "sistem geçişi" penceresi gerektirir. Hedef (yeni) birimlerde (R2'ER) okuma/yazma etkindi ve ana bilgisayar sistemlerinin FC bağlantıları (SAN bölge oluşturma ve maskeleme aracılığıyla) yeni diziye yönlendirilirdi.
SRDF/Metro'ya, VMAX All Flash depolama dizisi ailesi eklendi. SRDF/Metro, her iki diziden de kaynak (R1) ve hedef (R2) birimlerine gerçek aktif/aktif ana bilgisayar erişimi sağlar. SRDF/Metro, disk erişimi için desteklenen ana bilgisayar çoklu yol sürücüleriyle çalışır. Bu, disk yolları için yerel IBMi Dinamik Çoklu Yol (DMP) korumasını içerir. IBMi DMP, aynı disk aygıtında birden fazla FC yolu olup olmadığı otomatik olarak algılar. Disk G/Ç iş yükünü mevcut FC bağdaştırıcısı yollarına dağıtmak için basit ancak etkili bir "çevrimsel sıralı" yük dengeleme şeması da sağlar. IBMi DMP, bağlantılar başarısız olduğunda disk G/Ç işlemini kalan aktif yollardan birine yeniden yönlendirerek otomatik yol yük devretmesi sağlar. Başarısız bağlantılar geri yüklendiğinde, IBMi bu yolları otomatik olarak kurtarır ve bu yollara disk G/Ç'sini yeniden göndermeye başlar.
METRO ve ön kopyalama seçeneğine sahip NDM, eski ve yeni depolama aygıtlarına eş zamanlı erişim sağlamak için temeldeki SRDF/Metro teknolojisini temel alır.
OLUŞTURMA Aşaması:
Bir SRDF/Metro çoğaltma aygıtı çifti (R1>R2) oluşturulduğunda, hedef dizideki R2 aygıtından aynı R1 aygıt kimliği sunulur. Özet olarak, her iki aygıtta da aynı disk seri kimliği ve aygıt WWPN'si sunulur. Başlangıçta, yeni R2 aygıtı AA-NR/DEV-INACT (Etkin/Etkin-Hazır Değil/ Aygıt Etkin Değil) durumundadır. R1>R2 aygıt çifti senkronize edildikten sonra, R2 disk bölümüne Okuma ve Yazma erişimi etkinleştirilerek aktif/aktif duruma girebilir.
READY_TARGET Aşaması:
IBMi LPAR'dan R2 aygıtına giden yol artık etkinleştirildiğinde (SAN Bölgelendirme zaten mevcut ve NDM readytgt komutu tarafından etkinleştirilen yeni dizi için Maskeleme), IBMi anabilgisayarı, varolan disk aygıtına giden yeni FC yollarını keşfeder. Bir IBMi NDM senaryosunda, aktif/aktif R1 + R2 aygıtları sunulur.
COMMIT Aşaması:
R1 aygıtlarına erişimin kaldırılmasıyla, IBMi ana bilgisayarı artık eski dizinin yollarına erişimi kaybeder, ancak yeni dizinin yollarını kullanarak R2 aygıtlarında çalışmaya devam eder. Bu işlem tamamlandıktan sonra, eski diziye SAN bölgelendirmesi kaldırılabilir. Eski etkin olmayan yolları kullanmayı durdurmak ve aynı zamanda bu artık "eksik" yollarla ilişkili tüm hata iletilerini durdurmak için IBMi sistemindeki "çoklu yolu sıfırla" yardımcı programı çalıştırılmalıdır. Eski etkin olmayan yolları ve ilişkili DMPxxx disk donanımı kaynaklarını IBMi ana bilgisayarlarının aygıt yapılandırma veritabanından (IBMi depolama yönetimi bilgi havuzu) kalıcı olarak kaldırmak için bir İlk Program Yükü (IPL) yani yeniden başlatma gerekebilir, ancak bu zorunlu bir IPL değildir, bir sonraki planlanan IPL'ye kadar da bekleyebilir. Bu "eski" cihazların kaldırılması için: STRSST>Servis Aracını>Başlat Donanım Servis Yöneticisi>Başarısız ve Raporlamayan Donanım: 4. seçenekle kaldırmak için tüm eski disk kaynakları DMPxxx öğesini seçin ve Enter tuşuna basarak bunu onaylayın.
Dell STM
kullanılırken dikkat edilmesi gerekenlerVMAX için IBMi çoğaltma kontrolü için sık sık "depolama kopyalama hizmetleri araç seti" olarak da anılan STM, PowerMax depolama, bir veya daha fazla IBMi ana bilgisayarında yerel bir yazılım uygulaması olarak çalışıyor. Desteklenen SRDF yapılandırmaları için uzaktan çoğaltmayı ve VMAX, PowerMax dizilerinde SnapVX anlık görüntüleri için yerel çoğaltmayı kontrol edebilir. STM'nin iki çeşidi vardır: Standart Özellikler sürümü ve Genişletilmiş Özellikler sürümü.
STM, FC yolları boyunca depolama dizisiyle bant içi iletişim kullanır ve sistem çağrıları için ağ geçidi bekçileri olarak da adlandırılan küçük özel cihazlar kullanır. IBMi için ağ geçidi denetleyicileri, yapılandırılmamış disk birimleri bölümünde kalan özel küçük D910 GK tipi aygıtlardır. Bu ağ geçidi denetleyicileri çok desteklemez, birden çok tek ağ geçidi denetleyicisi genellikle normal ASP1 diskleri için kullanılan aynı yedekli yol kümesinde sunulur. En az dört kapı bekçisi kullanılması önerilir. Ağ geçidi bekçileri NDM geçiş sürecinin bir parçası değildir, bu nedenle geçişten sonra eski diziden ağ geçidi bekçilerine erişim kaldırılır ve yeni diziden yeni ağ geçidi bekçileri sunulur.
Standart özellikler:
Bu, yalnızca *SYSBAS depolama yapılandırması kullanan sistemler için kullanılır. *SYSBAS, Sistem ASP1 + herhangi bir ek Kullanıcı ASP'si (ASP 2-32) anlamına gelir. STM yalnızca kaynak düğüme kurulur ve bölünemez tek bir varlık olarak *SYSBAS içindeki tüm diskler için çoğaltma çiftlerini kontrol eder. Temel disk yapılandırmasında değişiklikler meydana geldiğinde; diğer bir deyişle, NDM "unspoofing" işleminin neden olduğu disk seri numarası değişiklikleri, IBMi kaynak ana bilgisayarında STM DISCOVER komutunu gerçekleştirmek yeterlidir. Yeni dizideki ağ geçidi bekçileri sunulduğunda DISCOVER seçeneğini çalıştırın. Bu, ana bilgisayardaki Entegre Dosya Sistemi'ndeki (IFS) yerel symapi veritabanını günceller (location= /var/symapi/db). STM ekranları artık yeni disk seri numaralarını da yansıtıyor. STM içinde çoğaltma aygıtı eşleştirmesinde herhangi bir sorun gözlemlenmesi durumunda, yeni bir yapılandırma kurulumuyla başlamak için yalnızca yükleme seçeneğini kullanmak da mümkündür. Bunun, VMAX-PowerMax depolama dizisinde zaten yapılandırılmış olan çoğaltma eşleştirme kurulumu üzerinde hiçbir etkisi yoktur. Temiz bir sıfırdan kurulum/kurulum için, önce mevcut yapılandırmadaki ilişkili YOLLARI ve ADIMLARI belgeleyin (GO MAINCTL>1, GÖRÜNTÜLER>seçenek 2'yi seçin, SİSTEM görüntüsü> için aşağıdaki örneğe göre YOLLAR ekranı için ekran görüntüsü oluşturun:
STM'den çıkın, /var/symapi klasörünü ve alt klasörlerini silin. EMCCTL kitaplığını silin. STM'yi çalıştırın, programı tekrar yükleyin. CRTSYMAPI'yi çalıştırın. GO MAINCTL, daha önce yapılandırıldığı gibi aynı YOLLARI yeniden ilişkilendirin. STM artık VMAX-PowerMax depolama dizisinden aktif çoğaltma eşleştirmesinin durumunu algılar ve görüntüler. STM operasyonları artık yeniden başlatılmaya hazırdır.
Genişletilmiş Özellikler:
Bu, bir ya da daha fazla "değiştirilebilir" iASP (bağımsız ASP) ile bir IBMi PowerHA kümesi kurulumu kullanan sistemler için kullanılır. Bu senaryoda yalnızca iASP çoğaltılır ve bu iASP veya çoğaltmaları PowerHA kümesi içindeki düğümlere sunulabilir. Her küme düğümü kendi *SYSBAS'ında (ASP1) zaten aktif. iASP, paylaşılan küme aygıtı etki alanı içinde değiştirilebilir bir kaynak olarak yapılandırılmıştır. Kümede genellikle iki veya dört düğüm vardır; Bu, kaynak olarak üretim düğümü ve her iki tarafta da bir uzak DR hedef düğümü ve bir SnapVX yedekleme düğümü olan 4 düğümlü bir küme için aşağıdaki örnek diyagramda belirtildiği gibidir:

iASP'yi veya çoğaltmalarını kullanmak için herhangi bir düğümden IPL gerekmez. iASP diskleri küme içindeki herhangi bir düğümde sunulduğunda iASP'nin bu düğüm tarafından kullanılabilmesi için VARY ON komutu gerekir. PowerHA kurulumunda, STM Kaynak sürümü Kaynak düğüme (EMCCTL Kitaplığında) kurulur. Diğer tüm düğümlerde (SRDF veya SnapVX hedef replikaları) Hedef sürüm kuruludur (EMCCTLC Kitaplığında). Tüm düğümler etkinken, bu kurulumdaki belirli işlemler için STM'de yerleşik bağımlılıklar ve denetim ve dengeler vardır; yani, iASP hala VARY ON durumundaysa bir düğümün disk erişiminin kaldırılması yasaktır. Düğümler arası iletişim için, tüm düğümlerde EMCCTL alt sisteminde çalışan bir STM sunucu işi vardır. Bu iş, küme IP arayüzleri genelinde düğümler içinde iletişim kurar. Tipik STM işlemleri, küme içindeki herhangi bir düğümden çalıştırılabilir. Bunun için her düğümde aynı STM diskinin, adaptörlerin ve yol yapılandırma dosyalarının bir kümesinin kullanılabilir olması gerekir. PowerHA için STM'nin ilk kurulumu sırasında bu dosyalar kaynak düğümden MAINCTL option-16 kullanılarak yapılandırılır ve bu da bu dosyaları hedef düğümlere, yani STM kurulum kitaplıkları EMCCTL ve EMCCTLC'deki IASPS, ISRCIOA ve IMAGE dosyalarına yayar. Bu dosyalar, DSPPFM EMCCTL/IMAGE ile de görüntülenebilir. Dosyalar, iASP yapılandırması için kullanılan diskler ve disk adaptörleri hakkında bilgi içerir. Adaptör kimlikleri ve disk seri numaraları bu dosyalarda saklanır ve STM işlemlerinde kullanılır.
Şimdi, NDM kimlik sahtekarlığı kaldırma işlemi tamamlandığında meydana gelen bir disk seri numarası değişikliğinin etkisini ele alalım. STM yapılandırma dosyaları hâlâ eski disk seri numaralarını içerir. Bu yapılandırma dosyaları güncellenene kadar çoğu STM işlemi artık işlevsizdir. Bu dosyaların güncellenmesi ve yayılması, ilk STM yüklemesi sırasında MAINCTL>Option-16 (iASP'yi yapılandırın) çalıştırılırken iASP diskleri ilgili PATH-STEP'teki hedef düğümler için kullanılabilir hale getirildiğinde yapılan işlemin aynısı yapılabilir. Bu dosyalar güncelleştirildikten sonra STM iASP işlemleri yeniden beklendiği gibi çalışır. Herhangi bir sorun ortaya çıkarsa iASP Yollarını/Adımlarını yapılandırma ve STM yapılandırma dosyalarını oluşturma veya yayma seçeneği-16 da dahil olmak üzere kaynak ve hedef düğümler için STM'nin yalnızca sıfırdan kurulumunu yeniden çalıştırmayı düşünün.
Not: Bu yeni kurulum sırasında, eski disk seri numaralarını içermeye devam ettiklerinden, mevcut yapılandırma dosyalarını tutma seçeneğini SEÇMEYİN.
Dell Destek hesabı olan kayıtlı kullanıcılar, bu STM sürümleriyle ilgili daha fazla bilgi için IBM i için SRDF/TimeFinder Manager yazılımını görüntüleyebilir.
Cihaz kimliği sıfırlama, diğer adıyla "kimlik sahtekarlığı" işleminden sonraki IPL için dikkat edilmesi gerekenler
NDM kimlik sahtekarlığı önleme işlemi disk seri numaralarını değiştirir. Bu, yalnızca IBMi LPAR kapalıyken yapılabilir. Bu işlem geçiş sonrasında planlı bir çevrimdışı bakım yuvasında yapıldığında dikkat edilmesi gereken bazı noktalar vardır. IBMi LPAR'ın etkinleştirilmesi, IBM PowerServer Hardware Management Console'dan (HMC) kontrol edilir, HMC, IBM PowerVM sanallaştırması için Hipervizör işlevini sağlar. Bu HMC de her LPAR'ın LPAR yapılandırması, yani CPU/MEM, adaptörler vb. hakkında ayrıntılar içeren en az bir LPAR profili vardır. LPAR ilk kez IPL-ed (IPL = İlk Program Yükü = önyükleme sırası) olduğunda, seçilen profilden yapılandırma ayrıntılarını okur. Profildeki özel bir sekmeye "Etiketli G/Ç" adı verilir. Etiketli G/Ç ayarları, LPAR'ın B tipi IPL sırasında Yük Kaynağı (LS) (= önyükleme diski) ve D tipi IPL sırasında "alternatif yeniden başlatma aygıtı", yani DVD veya teyp araması gereken yeri tanımlar. LPAR ilk kez başarılı bir şekilde IPL yaptıysa, son IPL bilgisi hipervizörde saklandığından profili tekrar okuması gerekmez. Bir sonraki IPL'de, LPAR profili özel olarak yeniden seçilmedikçe, varsayılan "mevcut yapılandırma" ayarı kullanılır. IPL'ler arasında LS denetleyicisi veya LS disk ayrıntıları için belirli değişiklikler varsa LPAR, değiştirilen LS diskini kabul etmez ve IPL başarısız olur. Bu, EĞER: LPAR, "geçerli yapılandırma" seçeneğiyle veya Etiketli G/Ç LS adaptörü "yok" olarak ayarlandığında etkinleştirilir. LS disk seri numarasının değiştirilmesi, LPAR'ın kabul etmeyeceği ve doğru profil seçiliyken bir etkinleştirmenin gerekli olduğu bir değişikliktir.
Aşağıdaki ekran görüntüsü, geçerli bir LS adaptörü seçiliyken geleneksel HMC LPAR profil görünümünü göstermektedir:

Aşağıdaki resim, VIOS 3.x /4.x ile HMC v10'un modern sürüm görünümünde aynı bilgileri göstermektedir.

PowerMax ve VMAX'te diğer yararlı bilgiler bulunur: Kesintiye Neden Olmayan ve En Az Kesintiye Neden Olan Geçiş En İyi Uygulamaları ve Operasyonel Rehberi
======================================================================================
PRATİK IBMi NDM Prosedürü:
#NDM (Non Disruptive Migration) procedure for IBMi host environments. #From VMAX>>>VMAX, VMAX>>>PMAX, PMAX>>>PMAX #Written: Q4-2021 #Author: Wopke Hoekstra CSA IBMi Global Practice #Version: 5 ========================================================================================== # Just for reference: PowerMax OS 5978 Levels: Name Release Level/Code Elm 5978.144.144 Elm SR 5978.221.221 Foxtail 5978.444.444 Foxtail SR 5978.479.479 Hickory 5978.669.669 Hickory SR 5978.711.711 ========================================================================================== #PREREQS: # MINIMUM Microcode Requirements: Foxtail (NDM IBMi support and NDM METRO-Mode available) # MINIMUM of 2 RF directors per array are required # Central external UniSphere/SE (SymCLI) server required with access to the source and target arrays # MINIMUM SE version of 9.1 ==================================================================================================== #Actual Customer Environment where this procedure was used: # "OLD" VMAX: SN# ckxxxxxxxxx/ckxxxxxxxxx / 5978.479.479 # "NEW" PMAX: SN# ckxxxxxxxxx/ckxxxxxxxxx / 5978.479.479 ============================================================================================================ #Suggested NDM procedure: METRO NDM with Pre-Copy #Also refer to the DELL EMC PowerMax NDM Whitepaper: Paragraph 3.2.4 / page 120 ============================================================================================================ #PROCEDURE: Metro-based NDM with precopy #NOTE: (NDM with precopy allows end users to copy application data from the source array to target array while the application is still running on the source array) #SAN requirements: #Existing Host FC IOA ports/WWPN's will be used to also zone to the new target array's FA-ports. NO NEED for additional host FC connections. #NOTE: The NEW array needs to be connected to the same SAN Fabric's as the OLD array. #For each zone; add the desired target-array's FA-port WWPN into the existing zone (already containing the host initiator WWPN and OLD array FA-port WWPN) #Or alternatively create new zones with same initiators to the new target-array's FA-ports #NOTE: For LPAR's using VIOS/VFC(NPIV) connections and when the environment is setup for Live Partition Mobility, the vFC's secondary WWPN will be included in the zoning/masking. #The secondary WWPN's will not be active and are not in the source array's Login History Table. NDM does not accept inactive WWPN's to be in the IG of the source host, hence the NDM VALIDATE and CREATE commands will fail. #WORKAROUND: Temporarily remove the secondary WWPN's from the source LPAR IG. After the migration, simply add these secondary WWPN's back into the new IG on the target array. #Setup-phase: #symdm –src_sid <SN of Source> -tgt_sid <SN of target> environment -setup symdm -sid 008 -tgt_sid 661 environment setup #NDM RDFGroup will be created. Now modify the SAN zoning to include the target-array FA-ports. #NOTE: No devices are presented from the target-array yet. #NOTE: You can already check if the existing initiator-WWPN's are actively logging in to the new array symaccess -sid 661 list logins -dirport 1d:4 #To check the environment at any time: #symdm –src_sid <SN of Source> -tgt_sid <SN of target> environment -validate symdm -src_sid 336 -tgt_sid 662 environment -validate symdm -src_sid 008 -tgt_sid 661 environment -validate Other commands to display further details: symdm -sid 336 -environment list symcfg -sid 336 list -rdfg all symcfg -sid 008 list -rdfg all #NOTE: Take a copy of the source-array's masking database before the activity: symaccess -sid 336 list view -all -v -detail>masking336_24Nov2021.txt symaccess -sid 008 list view -all -v -detail>masking008_24Nov2021.txt #Create Phase (with precopy: (run validation prior to execution)) #This creates an SRDF/Metro session with NDM attributes and puts the SRDF/Metro pair into adaptive copy disk mode. #It starts syncing data from R1 to R2. #Bias is on the Metro-based NDM source. #symdm create –src_sid <SN of Source> -tgt_sid <SN of target> -sg <SG to be Migrated> [-tgt_srp <target SRP>] [-tgt_pg <target PG>] -precopy #First validate: symdm create -src_sid 008 -tgt_sid 661 -sg SG_IBMPROD1_1 -precopy -validate #Then execute: symdm create -src_sid 008 -tgt_sid 661 -sg SG_IBMPROD1_1 -precopy #Check NDM status: #symdm –sid xxx list (-v) (-detail) #symdm –sid<SN of SRC or TGT> -sg <SG to be Migrated> list –v –pairs_info -detail (shows device pairing) #symrdf list -sid xxx (-rdfg xxx) (-sg xxx) #symstat –sid <SRC SN> –rdfg<RDFG of Migration> –type RDF –i xx symdm -sid 008 list #ReadyTGT Phase: #Moves RDF pair state from adaptive copy mode to Active/Active(in case of witness protection) or Active/Bias (without witness protection). #Target devices are moved into a read/write mode, It puts the NDM pair in Active/Active or Active/Bias mode #Masking view is created on the target array using the masking elements created during the create command. #symdm –sid <SRC or TGT SN> -sg <SG to be Migrated> readytgt symdm -sid 008 -sg SG_IBMPROD1_1 readytgt #Check status: #symdm –sid xxx list (-v) (-detail) #symrdf list -sid xxx (-rdfg xxx) (-sg xxx) symdm -sid 008 list #On the IBMi LPAR, check for new detected FC paths (to the devices on new PowerMax) #Logon to LPAR, go into System Service Tools: STRSST and go to "work with disks"> "disk configuration"> "9.Disk Paths" #Let the system discover the paths, this may take a few minutes, just hit F5 to refresh the disk path status screen and verify all disks have the new paths added. #Commit Phase (this is the actual cutover to the new array): #symdm –sid <SRC or TGT SN> -sg <SG to be Migrated> commit symdm -sid 008 -sg SG_IBMPROD1_1 commit #The masking views will be removed on the old source array. #On the IBMi LPAR, check for the old paths going into "failed" status (these failing paths are the paths to the old source array) #Zoning cleanup: Remove the old array's FA-ports from the respective zones for this LPAR. #Use SST procedure to run MULTIPATH RESETTER macro (this will prevent further error messages being sent to the QSYSOPR MSGQ until the system is IPL-ed) #After next planned IPL, the path status will be correct again, with only the new active paths listed. #ONLINE MIGRATION COMPLETED! ============================ #Remove NDM environment (ONLY after last migration is completed): #symdm -sid xxx -environment -list #symdm –src_sid <SN of Source> -tgt_sid <SN of target> environment -remove symdm -sid 008 -tgt_sid 661 environment -remove ============================================================================================================ #Reset Device external Identity (un-Spoof) (Optional OFFLINE operation). #Resetting the target's device external identity back to the original array-based identity of the NEW array (changes the IBMi disk serial number (= Vol.ID + Array-ID)) #THIS REQUIRES A SHUTDOWN OF THE IBMi LPAR! #Can be done as planned activity when the IBMi LPAR is doing an offline activity, and will be re-IPL-ed... I.e. for full backup, scheduled IPL, etc. #NOTE: When STM (SRDF/TimeFinder Manager for IBMi) is used on the migrated LPAR, it requires a reconfiguration or as a minimum a DISCOVER command action, due to the changing of the LPAR's disk serial numbers. #Refer to KB article 193832 for more info and procedure.
Yalnızca maskelenmemiş cihazların sahtekarlığı kaldırılabilir, bu nedenle önce geçerli maskeleme görünümünün ayrıntılarını kaydedin ve kaydedin, ardından MV'yi silin, sahtekarlığı kaldırın ve ardından MV'yi yeniden oluşturun.
symaccess -sid xxx show view -name xxxxxxxx >masking_xxxxxxxx.txt symaccess -sid xxx delete view -name xxxxxxxx
Disk kimliği ayrıntılarını görüntüleyin:
symdev -sid xxx list -identity_set symdev -sid xxx list -identity -sg <sg-name>
Tek bir cihaz için:
symdev -sid xxx reset -identity -dev xxx -nop
Çeşitli aygıtlar için:
symdev -sid xxx reset -identity -devs xxx:xxx -nop symaccess -sid xxx create view -name xxxxxxxx -sg xxxxxxxx -pg xxxxxxxx -ig xxxxxxxx symdev -sid xxx list -identity -sg <sg-name>
IBM HMC den, LPAR profilinde, "Tagged I/O" sekmesinde, LS denetleyicisinin doğru FC bağdaştırıcısına ayarlandığını doğrulayın.
Etiketli G/Ç" LS denetleyici ayarını "yok" seçiliyken boş BIRAKMAYIN.
B-Normal seçeneğine sahip IPL'yi seçin ve IPL için LPAR profilini seçin, bunu varsayılan "mevcut yapılandırma" seçeneğinde BIRAKMAYIN.
Şimdi LPAR'ı IPL edin ve sistem tekrar çevrimiçi olduktan sonra SST'den disk seri numaralarını doğrulayın.
Seri kimlikleri artık yeni dizilerin symdev kimliğini ve dizi seri numarasını yansıtmalıdır.
=== End of Procedure ===