數據遷移典型問題分析

數據遷移典型問題分析數據遷移典型問題分析/NUMPAGES17數據遷移典型問題分析數據遷移典型問題分析主機存儲基礎平臺數據遷移（存儲遷移、數據庫遷移、虛擬化遷移）典型問題分析一、存儲遷移活動中大量的問題是針對于不同品牌存儲直接的數據遷移，相同品牌存儲數據直接的遷移，使用存儲虛擬網關利弊等，下面是會員針對此類的問題的解決方法，技巧與相關參考意見。以下是幾個比較典型的問題：V7000和DS8000直接的數據遷移問題?1、不借助第三方工具，可以考慮使用基于系統的lvmmirror，aixlinuxhp-ux都支持也可以通過應用本身來做，如oracle的asm?；蛘遫raclerman的backupascopy以及db2的重定向恢復（但需要短暫停機時間）。2、只能基于主機或應用。如果一定要基于存儲做，建議使用svc3、使用svc即可。但也要有個短暫的停機時間。使用vdm或migration都可以4、完全不停業(yè)務的話考慮lvmmirror5、如果目前兩個環(huán)境都是獨立使用的情況下，不停機的遷移基本上不可能。因為不管你怎么做，前端主機都要有一個再識別的過程。前端加一個SVC可能會比較好。V7000這個產品如果用作去充當svc的作用的話，可能在性能上后續(xù)會差點意思。刀箱的盤陣列上的存儲數據，遷移到新的存儲上方法與考慮？目前刀箱上的磁盤是刀箱本地磁盤還是刀箱通過光纖模塊連接的外置存儲，這個需要說明一下。如果是刀箱內置硬盤，是否和本地刀片里的磁盤做過mirror。是否考慮遷移。是否配置連接存儲的光纖模塊。如果是通過光纖模塊連接的那也就沒什么了，和普通環(huán)境一樣。使用LVM的方式進行遷移。使用存儲網關，遷移同系列存儲和異構存儲考慮?1、IO能力：目前來說存儲網關產品配合著閃存可以覆蓋95%以上的應用，io能力在幾年內還是可以的。對于io極為苛刻的場景可以選擇其他的具體方案2、擴展能力：很多時候官方產品宣傳的很好，比如說我可以支持多少個節(jié)點的擴展能力，縱向到什么程度，橫行到什么程度。但我們需要進一步去看撥開宣傳華麗的面紗去看技術的實現。是成對的擴容啊，還是一個整體的擴容，其實現原理和規(guī)模是不太一樣的。3、兼容性是支持摸一個具體型號，還是支持摸一個品牌系列，這里邊有很多種學問。會不會因為實施了虛擬網關后整體的io能力反而下降了，是產品不行還是實施的方案不對，曾經有的客戶抱怨實施后的應用io能力下降了。這個里邊需要做的工作太多了。不同品牌的主機或存儲服務器之間進行數據遷移？1、底層存儲用svc或vplex虛擬化，隨時可以進行數據遷移，無需申請停機窗口2、使用存儲虛擬網關產品對于前端主機是透明的，可以忽略底層數據的存放和遷移工作，前段主機安裝一種多路徑軟件，管理維護性比較好。存儲經常會報警：鏈路不在最優(yōu)路徑上，診斷處理思路？1、lun鏈路不在最優(yōu)路徑是指在創(chuàng)建lun是選擇lun所在控制器的優(yōu)先級，就是lun首先被那個控制器管理，如果不在這個控制器就會提示你說的那個錯誤，這種情況下把lun切過去就可以了，如果經常發(fā)生這樣的錯誤告警提示就得注意了，檢查鏈路，控制器日志等等2、排除了zone配置，一般都是鏈路問題。ds4kds5k系列有時候切回到最優(yōu)路徑還會報錯。臨時解決方法：自己切自己，空切玩就沒事了3、很多時候經常會遇到主機掃描新映射的磁盤的時候存儲鏈路就會切換的情況的出現，手工切換回去也就老實了，也沒事。4、有的時候經常是因為主機hba卡故障導致鏈路不在最優(yōu)路徑上。曾經vmware集群多臺機器中的一臺hba卡故障，導致存儲上出現鏈路切換的工作。換了就OK。5、出現鏈路切換的時候大多還是鏈路方面的問題，比如線路不太穩(wěn)定，嘗試換一端口嘗試解決一下。曾經碰到一次鏈路衰減的問題，識別巨慢，讀寫都不正常，換條線換個口基本上可以解決此類問題。分析：以上此類問題大多聚焦于存儲層面的數據遷移工作，主要是相同品牌之間和不同品牌之間。經過多年的發(fā)展，存儲虛擬網關已經是非常成熟的產品，每個廠商的產品名稱不一樣，但是效果大多還是不錯的。除了個別存儲兼容性以外，主要考慮的就是存儲虛擬網關的性能與后期擴展性方面。存儲虛擬網關對前端主機透明，很好的屏蔽或封裝了后端存儲的復制性。提高了管理和運維的效率。存儲虛擬網關已經是此類場景一個比較成熟的解決方案，后續(xù)其他應用場景廣大同仁可以參考使用。二、數據庫遷移還有很多問題主要關注的是主機數據庫平臺，遇到數據庫遷移問題的描述，希望了解通過哪種方式可以降低RTO和RPO，盡可能的在線完成存儲，主機或數據本身的方面的遷移。這里將此類問題進行一個梳理，為后續(xù)此類數據遷移場景提供一個參考。OracleRAC生產系統，存儲和主機都要更換？1、之前一個基于ORACLE的項目策劃，在測試環(huán)境通過，但沒有最終實施測試環(huán)境是RHEL6.5ORACLE11201，其中主機部分是通過添加RAC節(jié)點并通過數據庫服務模式來逐臺更換，存儲部分是通過ASMNOR切換。2、主機和存儲都要換的話還是比較繁瑣的，當然需要做一些嚴格測試工作，工作需要做的充分一些。存儲端的在線遷移相對來說簡單一些，只是主機端多路徑設備識別一塊可能有限異常，可能需要重啟，這個可以逐臺進行，后續(xù)ASM在線遷移一般不會有什么大的問題。主機端目前不停機的辦法好像只有rac添加節(jié)點和刪除節(jié)點一種方式比較合適了。3、嘗試一下RAC+DG的方式RAC環(huán)境遷移到云環(huán)境？1、OracleRAC或者oracle從Power到X86或者是X86到Power平臺之間的遷移由于系統平臺不一樣，文件識別的字節(jié)序等方面不一樣，不能直接使用物理文件拷貝或者rman恢復的方式進行。遷移參照辦法：-使用導入導出方式-使用表空間傳輸方式。至于說能不能遷移主要是考慮，業(yè)務系統是否支持或者是否需要其他特殊的要求，和內網有無大數據量的交互，有關性能一個方面不是太大的問題，可以通過其他方式解決。架構問題，每個企業(yè)都不一樣，且業(yè)務場景不同。需要依據具體情況實施。2、如果考慮把數據庫遷移到云上，可以有兩種方式交付，一種是通過從云服務提供商采購虛機，在虛機集群上構建oracleRAC，但是需要考慮RAC集群的性能問題，是否仍然能夠滿足之前的業(yè)務容量需求；另外一種交付模式就是類似阿里云RDBS的云數據庫模式，用戶比較省心，不必擔心性能問題，成本也比較低。3、Oracle從Power架構遷移到云上是不存在任何技術障礙的，問題的關鍵是在于現有的應用架構是否能支撐基于云的計算，另外，如果云主機提供的處理能力無法匹配現有Power主機的處理能力，那么數據庫架構也需要進行調整。X86RAC遷移到Power平臺RAC1、感覺這個還是看停機窗口和數據量。因為跨平臺了，如果停機窗口足夠可以使用數據泵導出再導入的方式。這樣操作起來比較簡單。如果停機窗口不夠，可以考慮使用ogg之類的復制方案來做。2、參考RAC遷移云環(huán)境的解決思路。關于數據倉庫跨品牌數據庫遷移、數據異地同步1、第一如果你的業(yè)務遷移涉及到數據庫品牌切換，這個就需要完整的廠家解決方案來確認了，比如從DB2遷移到ORACLE，這就需要2個品牌（主要是ORACLE）的廠商來確認數據的可用性，另外ORACLEOGG，QUESTSharePlex號稱可以在異構平臺上進行不同數據庫的數據同步，但沒有測試，不敢確定，2、另外異地同步，已經類似傳統兩地三中心的第三中心了。在帶寬有限制的情況下，推薦本地雙活、異地容災/實時備份OracleRAC從HP存儲遷移到IBM存儲1、這種跨平臺的遷移，很難直接通過基于塊的存儲復制遷移。最后通過數據庫本身提供的工具。以oracle為例，跨平臺的遷移可選擇數據泵導出，再導入的方式。也可以選擇ogg、dsg等數據庫復制軟件。具體選擇哪種方案，以停機窗口和數據量大小來綜合判斷。2、如果只是更換存儲的話，主機端使用參考使用LVM方式，主機識別多個存儲，rac前端進行遷移也是可以的。DB2遷移Oracle的相關問題問題1：非空字段判定：DB2可在非空約束中插入空字符串，且大量存在業(yè)務表中，但Oracle不允許此類數據存在解答：在遷移的時候進行轉換問題2:數據庫對象長度不同：DB2數據庫存在較多超長的數據庫對象名，但Oracle最多支持30個字符。解答：目前還是無解的問題3：自增列的遷移：DB2存在自增列，Oracle沒有相關匹配？解答：可以在遷移完成后再添加序列對象實現分析：在數據層面的數據遷移還是比較多，主要涉及的幾個方面：存儲更換，主機更換，不同數據庫之間的轉換遷移，數據所在平臺的遷移。數據庫層面的遷移問題，在此只是做了簡單梳理，其實還有大量的問題由于時間問題沒有提出來，比如oracle如何遷移至mysql，sqlserver等，其他數據庫直接的相互遷移或轉換。是否已經有比較成熟的產品供我們參考利用，在實際遷移過程當中又遇到過哪些疑難雜癥，后續(xù)我們可以準備針對數據庫方面遷移做一些探討。本次活動當中涉及到的數據庫層面層面遷移相應的參考借鑒方案主要有以下幾種：1.使用虛擬網關遷移屏蔽存儲的遷移2.使用LVM一臺主機掛接多個存儲完成存儲更換3.使用rac或dg完成oracle層面的遷移4.使用第三方工具進行數據層面的遷移或轉換。三、虛擬化遷移本次涉及到的虛擬化遷移主要包括vmware平臺，powervm平臺以及vmware平臺和其他虛擬平臺直接的遷移轉換的問題與思考。VmwareP2V常用場景1、vmware4.1可以使用的集群的安裝插件在集群上選擇導入的方式進行p2v的轉換。2、在從5.0版本以后，好像已經不能再集群端進行直接的導入方式，只能選擇使用VMwarevCenterConverterStandaloneClient進行轉換，在兼容模式下的操作系統基本上問題不大。3、還可以考慮在主機端直接手工安裝agent或者使用coldconverter光盤進行遷移。4、曾經遇到一個只有256Ｍ內存的windows執(zhí)行在線導入的操作，由于內存太低不支持，后來擴容到512就好了。5、還有一些時候經常會在p2v遷移到了99%以后報錯，次遷移就Ok，每次情況可能都不一樣。很多時候因為網絡或者其他不穩(wěn)定，具體情況具體分析。6、我個人覺得實際生產中一般肯定是冷的，7、假設是數據庫，熱的肯定不一致了。8、應用，沒必要遷移了，直接搭建環(huán)境，發(fā)布應用就可以了。簡單快速，不停業(yè)務。9、我覺得是一些開發(fā)環(huán)境，安裝配置比較復雜的環(huán)境適合p2v。VMWARE虛擬化環(huán)境，更換新的存儲1、vmware的vmotion就是來干這個事的。大多情況下還是使用vmware的vmfs形式去做的，直接在線遷移即可，如果存儲做過心跳信號的，要注意把老舊的刪除，新存儲的添加2、配置好vMotion，沒有裸映射的虛擬機之間遷移，如果有裸映射需要設置成虛擬模式才可以遷移成虛擬磁盤，大于2T的需要在webclient里面遷移3、使用vmware自帶的storagevmotion功能即可，在線遷移虛擬機磁盤小型機全分區(qū)環(huán)境向PowerVM全虛擬化環(huán)境遷移1、你需要一臺光纖存儲和san網絡,然后升級待遷移小雞的AIX系統補丁，支持sanboot把小機上的rootvg和其他vg遷移到光纖存儲上，用mirrorvg和unmirrorvg關掉舊小機.在新小機上創(chuàng)建新的虛擬機掛載對應的磁盤，開機就好。因為網卡發(fā)生變動了，所以新的小雞需要重新設置IP地址，就完成遷移工作了2、在于原來的規(guī)劃，rootvg只做系統，系統無非都是文件系統，都可以拷貝的，重要的datavg（應在存儲中）也可以在新系統中（powervm）重新導入Vmware遷移到KVM1、virt-v2v工具是專門針對VMwareESX/ESXi的自動化遷移工具，而且支持的虛擬機系統僅限于RHEL和Windows虛擬機。Virt-v2v在遷移后的KVM虛擬機中優(yōu)先使用virtio虛擬驅動來提高系統IO的性能。如果不支持，才選用性能稍低，但更穩(wěn)定可靠的虛擬硬件。而且這個過程全部自動化完成。2、手動遷移可以涵蓋所有的VMware軟件和所有的虛擬機系統。從而遷移中面臨的問題也是多樣化的，需要不同程度的手動干預。某些特定的環(huán)境下，可以使用一些工具來輔助手動遷移，比如virt-goodies/vmware2libvirt。另外libvirt也在開發(fā)支持VMwareWorkstation/Player遷移的新功能。3、不論是virt-v2v自動化工具還是手動遷移，由于商業(yè)軟件VMware開放的編程接口的限制，VMware虛擬機到KVM的遷移有一些軟肋：一些VMware虛擬機的特性沒有辦法遷移到KVM虛擬機上。比如VMware虛擬機廣泛使用的快照功能。只能實現關閉虛擬機情況下的靜態(tài)遷移，無法做到虛擬機不關機情況下的在線遷移。一些特殊的VMware設備不能遷移到KVM虛擬機，于是采用了類似功能的硬件設備替代。比如VMwareTools中的虛擬驅動、VMwareSVGA、VMwareUSBController等?？偟膩碚f，VMware虛擬機到KVM的遷移不夠成熟和自動化，遷移的過程需要手動干預。這要求遷移的操作人員具有相關的知識和