999精品在线视频,手机成人午夜在线视频,久久不卡国产精品无码,中日无码在线观看,成人av手机在线观看,日韩精品亚洲一区中文字幕,亚洲av无码人妻,四虎国产在线观看 ?

基于KVM的虛擬機Post-Copy動態遷移算法穩定性優化

2021-08-13 02:57:58陳雙喜趙若琰劉會吳春明阮偉
電信科學 2021年7期
關鍵詞:頁面故障

陳雙喜,趙若琰,劉會,吳春明,阮偉

(1. 浙江大學,浙江 杭州 310058;2. 嘉興職業技術學院,浙江 嘉興 314036; 3. 嘉興市工業互聯網安全重點實驗室,浙江 嘉興 314036)

1 引言

云計算的思想源于20世紀 60 年代,真正進入大眾視野是在 2006 年 8 月, 由 Amazon 子公司 Amazon Web Service(AWS)推出第一款云計算產品 Elastic Compute Cloud[1]。近年來,隨著云計算的蓬勃發展,網絡服務功能和占比總量快速增加,云計算技術受到了廣泛關注和應用,其中最重要的是虛擬化技術。虛擬化技術是一種在計算機物理資源之上抽象并進行有效管理的技術[2]。目前常見的虛擬化管理工具有 VMware[3]、KVM[4]、Xen[5]、Hyper-V[6],借助虛擬化技術能提供比原先多臺物理主機更有效的計算,同時還能節省硬件成本和降低能源損耗。虛擬機遷移大體可以分為兩種,分別為靜態遷移(non-live migration)和動態遷移 (live migration),本文著重討論虛擬機的動態遷移。目前,虛擬機動態遷移有兩種常用的算法:Pre-Copy(預拷貝)和Post-Copy(后拷貝)。不同算法有不同的特點,預拷貝遷移算法的停機時間較短,但是其迭代復制的操作,可能會導致遷移過程無法收斂,總體遷移時間過長;后拷貝遷移算法的停機時間短,總體遷移時間穩定,但虛擬機在遷移過程中會出現缺頁錯誤導致虛擬機性能下降,并且整個遷移過程缺乏穩定性[7]。 綜上所述,虛擬機的動態遷移在云計算領域有特殊的地位,各種動態遷移算法還存在許多亟待解決的問題,因此研究優化動態遷移算法,對解決現有算法存在的問題具有十分重要的意義。

主流動態遷移算法中,預拷貝遷移算法被研究得相對較多。預拷貝遷移算法由Clark等[8]在 2005 年首次提出,如今大多數虛擬機管理程序,例如 Xen、 KVM 和 VMware,都將預拷貝作為默認的虛擬機遷移算法。預拷貝遷移算法的問題在于,面對寫密集型程序,內存不斷被寫入形成大量臟頁,遷移過程中會將同樣一個頁面傳輸多次,且有可能整個過程無法收斂,因此大部分的研究著重解決這個問題。后拷貝遷移算法由于其實現相對復雜,算法中存在的問題比較突出,可優化的點較多,近年來成為了國內外研究的重點。針對后拷貝遷移算法存在的問題, 研究主要分為兩個方向:減少缺頁錯誤和容錯機制。為了減少后拷貝遷移中缺頁錯誤產生的次數,Chashoo等[9]研究了將預拷貝的思想引入后拷貝中,提出了一種使用內存膨脹技術,內存膨脹技術可以在需要時減少空閑頁面和未使用頁面從而減少虛擬機內存頁面的數量,使得源端虛擬機需要傳輸到目標端虛擬機的頁面數減少,降低內存利用率。Shan等[10]在 Xen 上設計并實現了遠程頁表助手(remote page table assistant)的功能,當發生缺頁錯誤時,Xen通過該功能直接獲取當前虛擬機是否正在遷移的信息,當虛擬機正常運行時,Xen忽略虛擬機監視程序的判斷過程,并快速調用預設的缺頁處理函數處理缺頁錯誤。Su等[11]提出了一種遠程缺頁錯誤過濾器(RPFF),在后拷貝遷移過程中,通過將客戶程序的內存頁面重寫操作請求重定向到一塊新分配的本地內存中,從而消除了不必要的缺頁錯誤,避免從源端虛擬機獲取頁面,減少因為重寫造成缺頁錯誤所帶來的額外消耗,特別強調針對內存寫入密集型的工作負載,其整體性能會有極大提高。Jalaei 等[12]通過降低后拷貝遷移算法中虛擬 CPU 的執行速度,將目標端虛擬機中的頁面處理速度與源端虛擬機的頁面傳輸速度平衡,從而降低缺頁錯誤產生的次數。孫淑嫻[13]提出通過預先執行虛擬機程序預測目標端虛擬機將要訪問的內存頁面,提前傳輸到目標端虛擬機從而降低缺頁錯誤率,并利用局部性原理動態調整所需傳輸的頁面數量。對于后拷貝遷移的容錯機制,現有的研究還比較少,目前的研究方向主要基于檢查點,檢查點簡單來說是一種備份記錄的方法,通過檢查點記錄虛擬機歷史的狀態。Fernando 等[14]提出了一種反向連續檢查點技術,通過設置檢查點定期記錄虛擬機的增量狀態變化信息,當虛擬機出現故障時可以由保存的最新檢查點狀態進行虛擬機狀態的恢復。Chou等[15]提出一種基于檢查點和FAM(fabric- attached memory)的后拷貝遷移算法,FAM是一種特殊的可以使內存進行光纖級通信的機制,通過將整個遷移過程的內存空間映射到FAM,將數據通信簡化成內存語義,極大地減少了缺頁錯誤的處理時間,并使用Linux 開源檢查點工具 CRIU 實現了檢查點的功能。

可以看出,目前針對后拷貝遷移優化研究相對較少,雖然取得了一定的成果,但是仍然有許多地方值得挖掘,無論解決缺頁錯誤問題還是容錯機制都存在很大的提升空間,因此針對該領域的研究是很有挑戰且充滿意義的工作。本文通過分析后拷貝遷移算法中存在的穩定性問題進行深入研究和分析,提出了基于事件同步的故障容錯方法,結合檢查點與事件同步技術實現了故障場景檢測以及對應場景的故障恢復。

2 問題分析及優化方案

2.1 后拷貝遷移算法基本流程

后拷貝遷移算法的基本流程如圖1所示。在整個遷移過程中,源端虛擬機和目標端虛擬機主要在兩個階段進行數據交互。

圖1 后拷貝遷移算法的基本流程

? 第一階段:在遷移之初,通過暫停源端虛擬機,將必要的CPU狀態和設備信息傳輸到目標端虛擬機,由目標端虛擬機繼承并恢復運行被暫停的虛擬機狀態。

? 第二階段:在遷移過程中,由暫停的源端虛擬機主動傳輸剩余的內存頁面到目標端虛擬機。當目標端虛擬機正常運行的過程中出現缺頁錯誤時,將發送請求到源端虛擬機,請求提前獲取缺失的內存頁面。

2.2 穩定性問題

遷移機制本身的穩定性是虛擬機動態遷移算法優劣評價標準中一項重要的考慮因素。遷移過程中虛擬機的狀態分別分布在兩臺虛擬機上,源端虛擬機擁有內存頁面,而目標端虛擬機擁有正在運行的虛擬機上下文信息,總體呈現一種割裂的狀態,因此保證兩臺虛擬機之間數據交互渠道的穩定性至關重要。但是在虛擬機實際運行過程中,很可能頻繁受到攻擊,特別在遷移過程中受到攻擊的影響更大。虛擬機遷移可能持續幾秒到幾分鐘不等,導致漏洞被攻擊的窗口可能性很大[14]。因此原始的后拷貝遷移算法中兩臺虛擬機的交互渠道不能保證絕對的可靠。

后拷貝遷移過程中虛擬機的最新狀態分布如圖2所示。虛擬機的最新狀態分別存在于源端虛擬機和目標端虛擬機之上,目標端虛擬機具有最新的虛擬機 CPU 運行狀態、設備信息和內存頁面的部分子集,而源端虛擬機具有尚未發送到目標端主機的剩余內存面。如果目標端虛擬機出現故障,此時虛擬機的CPU 狀態、設備狀態和已經傳輸到目標端虛擬機的內存頁面將丟失,并且由于源端虛擬機上并沒有可以支持虛擬機重新運行的相關數據,不僅會導致后拷貝遷移失敗,還會造成虛擬機和使用虛擬機服務的用戶程序丟失。而如果源端虛擬機出現故障,目標端虛擬機也會因為當發生缺頁錯誤時無法請求源端虛擬機對應的內存頁面,一直處于暫停等待的狀態,導致整個遷移過程陷入停滯,最終導致遷移失敗。

圖2 虛擬機最新狀態分布

2.3 優化方案

對于穩定性問題,通過分析發現無論是源端虛 擬機的故障還是目標端虛擬機的故障,都會導致后拷貝遷移的失敗,因此本文對兩種虛擬機故障場景提出對應的容錯解決策略,具體采用檢查點與幀同步相結合的方式,通過記錄檢查點確定故障恢復的起始狀態,利用幀同步對可能發生的不確定性事件進行同步重播。并且為使用更少的虛擬機資源減少額外開銷,選擇在不增加額外的備份虛擬機基礎上進行故障容錯。優化方案設計如圖3所示。

圖3 優化方案設計

3 基于事件同步的故障容錯方法

針對后拷貝遷移算法中存在的穩定性問題,提出了基于事件同步的故障容錯方法,首先介紹了基本的故障容錯架構,其次針對技術細節的實現進行闡述,最后對典型的故障場景進行分析并提出了對應的故障恢復方案。

3.1 基本架構

基于事件同步的故障容錯方法,在QEMU-KVM平臺基礎上進行修改實驗,主要目的是為后拷貝遷移提供故障容錯機制,保證當源端虛擬機或目標端虛擬機出現故障時,對應的虛擬機狀態不會丟失。本文方法實現的關鍵點主要可以分為不確定事件的記錄和同步、增量式檢查點的記錄、數據的傳輸與存儲、故障檢測及修復。

3.2 不確定事件記錄和同步

首先需要知道如何正確記錄所有的不確定性事件。就整個 QEMU-KVM 平臺而言,不確定性事件等同于記錄不確定性敏感指令,即會對當前宿主機行為造成影響的指令。當虛擬機需要執行指令時,會觸發 VM exit,由非根模式進入根模式進行對應的處理操作。在后拷貝遷移過程中,可能會造成行為發生變化的不確定性敏感指令可分為4種類型:中斷、PIO(programmed I/O)、MMIO(memory mapped I/O)和缺頁錯誤訪存指令。除了需要記錄不確定性事件具體的操作指令和相關數據,還需要正確記錄指令發生的時間點。記錄指令發生的時間點等同于記錄一段時間內 CPU 總共執行的指令次數,但是由于指令次數沒有特定的 CPU 寄存器保存,無法直接從基本的寄存器中取到,因此需要額外的操作獲取執行的指令次數。

3.3 增量式檢查點記錄

當遷移過程發生故障時,如果從虛擬機的最初狀態開始進行恢復,除了需要保存大量的事件信息,還會導致恢復所花費的時間過長。因此本文在目標端虛擬機運行過程中引入檢查點機制,檢查點與檢查點之間定義為一個回合,將整個運行過程劃分為多個獨立的回合。記錄每個回合開始的檢查點以及當前回合內發生不確定性事件的相對時間點,當出現故障需要進行恢復時,可以從距離當前錯誤時間點最近的上一個檢查點開始進行具體的恢復流程。

事實上,在虛擬機實際運行過程中,大多數的內存頁面是保持不變的,如果只記錄產生變化的內存頁面,就能有效降低總體的快照消耗。對于內存 1 GB 的虛擬機,CPU 狀態和設備狀態只占約 600 KB,因此對于占比較少的CPU 狀態和設備狀態選擇直接進行記錄,不做增量的計算,只對內存狀態的增量變化進行記錄。內存狀態的增量變化情況如圖4所示。

圖4 內存狀態的增量變化情況

記錄內存狀態的增量變化,需要獲取當前檢查點相對于上一個檢查點時的內存頁面寫臟情況,利用 KVM 內核提供的寫保護機制可以完成對臟頁情況的追蹤。增量式檢查點記錄的起點位于后拷貝遷移開始前,由源端虛擬機記錄完整的內存狀態保存到共享磁盤。當遷移開始后,目標端虛擬機接管虛擬機狀態并開啟臟頁同步,通過內核定時器定時記錄 CPU、設備狀態和內存增量變化,構建相應的檢查點數據并進行傳輸和保存。當故障發生時會從最初的完整內存數據開始,按順序對每個增量式檢查點進行同步,直到同步到最后一個檢查點為止。但是順序同步檢查點數據可能帶來重復的頁面讀寫,因為內存頁面很可能在多個檢查點被記錄。因此,針對這一問題使用哈希圖的方式,保存每一個頁面被記錄最新的檢查點編號。在進行故障恢復時,可以通過哈希圖對每個頁面只同步一次,從而減少冗余的內存數據讀取,減少故障恢復時間。

3.4 數據的傳輸與存儲

對于記錄的不確定性事件信息與檢查點信息,需要使用合理的數據格式保存到合適的數據存儲工具中,以便在故障恢復時能夠及時獲取需要的數據。檢查點與不確定性事件的傳輸流程如圖5所示。具體而言,由 QEMU 通過kvm_ vm_ioctl(KVM_GET_DIRTY_LOG)系統調用設置內核定時器,定時觸發VM exit 使客戶程序退出非根模式開始記錄檢查點數據,QEMU 獲取內核數據通過內存映射的方式實現。

圖5 檢查點與不確定事件數據傳輸流程

相鄰檢查點之間作為一個回合。每個回合之初,記錄 CPU、設備狀態以及內存頁面增量變化,構建檢查點數據,傳輸檢查點數據到Redis服務器,并重新設置內核定時器以便進行下一次檢查點的記錄。每個回合中,當客戶程序產生不確定性事件時,記錄不確定性事件的信息和發生的時間點,構建不確定性事件數據。為了避免每次發生不確定性事件都進行一次數據傳輸,通過創建內核事件緩沖區緩存不確定性事件,當事件緩沖區已滿或者當前為輸出事件時,將緩存的所有事件一并傳輸到 Redis 服務器。每個回合結束即觸發定時器開始下一個檢查點回合時,會將事件緩沖區清空。每個回合重復上述流程對檢查點數據與不確定性事件數據進行存儲,直到遷移過程結束或者遷移出現故障開始對應的恢復流程。

3.5 故障檢測及修復

后拷貝遷移過程中可能出現的故障錯誤包括源端虛擬機故障、目標端虛擬機故障和網絡故障。對于源端虛擬機故障恢復,此時目標端虛擬機仍處于運行狀態但后拷貝遷移過程被中斷,導致部分內存頁面仍未傳輸到目標端虛擬機,當目標端虛擬機再次出現缺頁錯誤時無法請求對應的頁面。因此目標端虛擬機需要在產生缺頁錯誤時檢測源端虛擬機是否正常,如果檢測源端虛擬機故障,那么不再記錄不確定性事件和檢查點信息,直接從共享磁盤中,讀取后拷貝遷移開始時由源端虛擬機保存的最初的內存頁面狀態,并將仍未傳輸到目標端虛擬機上的內存頁面進行同步。整個過程完成后代表源端虛擬機故障的情況成功恢復,同時也代表后拷貝遷移完成。

對于目標端虛擬機的故障。此時需要由源端虛擬機接管虛擬機的運行狀態,相較源端虛擬機故障恢復過程會更復雜?;静襟E是,源端虛擬機讀取歷史增量式檢查點信息,載入檢查點中保存的 CPU 狀態、設備狀態和內存狀態到虛擬機之中,載入完畢后開始進行不確定性事件的同步。要進行不確定性事件的同步重播,意味著在正確的指令執行時間點暫??蛻魴C程序插入對應的事件指令,其重點在于如何正確進行事件指令的插入。

對于網絡故障的檢測與恢復,無論上述兩種虛擬機故障還是網絡故障的檢測,采用的方法都是一致的。對于源端虛擬機和目標端虛擬機,互相使用心跳機制發送 UDP 報文檢測對方是否出現故障。

4 實驗及評估

4.1 實驗環境及設置

本文的實驗環境為兩臺物理主機配合一臺交換機所連接的虛擬化平臺,其中一臺作為源端主機,另一臺作為目標端主機,分別于對應主機上創建虛擬機進行遷移實驗。此外源端主機還作為 NFS 服務器和 Redis 服務器,提供虛擬機的共享存儲服務與故障容錯數據的緩存服務,實驗網絡架構如圖 6 所示。

圖6 實驗網絡架構

兩臺實體主機的配置完全一致,分別配備了 Intel(R) Core(TM) i5-10400F 2.90 GHz 處理器, 8 GB 內存,RTL8125吉比特以太網卡,250 GB M2 固態硬盤,以及 Ubuntu-16.04-desktop-amd64 操作系統。兩臺主機均通過 Bios 開啟 Intel-VT 硬 件虛擬化服務,并通過吉比特交換機進行數據傳輸。其中,源端主機作為 NFS 系統服務器,存放修改后的 QEMU-KVM 虛擬機代碼與磁盤鏡像,并將對應的 NFS 文件夾掛載到另一臺主機實現共享存儲。宿主機上創建的虛擬機,使用相同的 IMG 磁盤鏡像,均配置一個虛擬CPU。

虛擬機通過橋接網絡的形式,獲取獨立的 IP 地址與外界進行網絡通信。測試基于事件同步的故障容錯方法。故障容錯方法通過定時任務的方式,每間隔一段時間記錄檢查點和不確定性事件數據。引入故障容錯方法必然會對正在運行的客戶程序性能造成一定的影響,因此需要通過實驗測試并選擇合適的數據記錄間隔時間,盡可能降低對性能的影響。具體測試的內容有平均每回合記錄數據的時間消耗、整個遷移過程中記錄數據的時間消耗、平均故障恢復時間以及故障容錯方法對客戶程序性能的影響。

4.2 實驗負載

實驗負載分別為SPECjbb2005、kernel-build、netperf和sysbench-oltp,具體的實驗負載說明如下。

(1)SPECjbb2005:用于測試工業級 Java 應用性能的基準測試工具,通過修改 SPECCjbb. props 文件設置測試線程的并發數量,通過生成高并發業務操作測試 Java 應用的處理能力。屬于CPU 密集型程序,同時伴隨有少量的 I/O 操作。

(2)kernel-build:使用單線程編譯 Linux-3.1.0 版本的內核代碼,內核編譯屬于可以測試綜合性能的平衡型程序。

(3)netperf:netperf 基于服務器/客戶端模式,通過 TCP 和 UDP 傳輸,對不同網絡傳輸方式的性能進行測試。其中,以 netserver 作為服務端監聽客戶端請求,netperf 本身作為客戶端向服務端發起網絡測試。通過配置建立連接,使用不同的網絡傳輸方式傳遞數據測試網絡性能。實驗中通過每次連接都重新創建 TCP 連接模擬 HTTP 的訪問模式,模擬大量的網絡 I/O 操作,屬于網絡 I/O 密集型程序。

(4)sysbench-oltp:sysbench 是一種多功能的基準測試工具,可以用于測試模擬不同系統參數下的數據庫負載情況。實驗中使用 OLTP 基準測試,測試 MySQL數據庫的聯機事物處理性能,模擬大量訪問數據庫的磁盤 I/O 操作,屬于磁盤 I/O 密集型程序。

4.3 實驗結果及分析

不同負載下平均每回合數據記錄時間消耗如圖7所示。平均每回合數據記錄所需的時間與數據記錄的間隔時間長度成正比。主要原因是,數據記錄的時間取決于記錄間隔時間內產生的臟頁和不確定性事件數量,因此數據量越多,記錄所需要花費的時間越長。但是間隔時間短反而會導致記錄的回合數更多,單從平均每回合的數據記錄時間來看,并不能決定最合適的數據記錄間隔時間,因此還需要對比整個遷移過程中記錄數據的時間消耗。

圖7 不同負載下平均每回合數據記錄時間消耗

不同負載下整個遷移過程中記錄數據的時間消耗如圖8所示。由圖8中可以看出,隨著數據記錄間隔時間的增長,數據記錄所消耗的總時間呈下降趨勢。這是因為,數據記錄間隔的時間越短,同步臟頁位圖與不確定性事件的頻率越高,導致整個遷移過程中需要記錄的數據量越多, 從而增加了數據記錄所消耗的總時間。因此可以認為,數據記錄間隔時間為 1 000 ms時,所帶來的數據記錄消耗最小。但是選擇合適的數據記錄間隔時間,除了需要考慮數據記錄的時間消耗性能指標之外,還需要考慮平均故障恢復時間這一重要性能指標。

圖8 不同負載下整個遷移過程中記錄數據的時間消耗

不同負載下的平均故障恢復時間如圖9所示。由圖9可以看出,不同的數據記錄間隔時間平均故障恢復時間相差不大。故障恢復時間代表當遷移過程中虛擬機出現故障時,需要停止虛擬機服務重新恢復虛擬機運行的這段時間。故障恢復時間的長短取決于需要讀取的頁面和不確定性事件數據的數量,數據量越多導致故障恢復的時間越長。對于相同的負載,在整個遷移過程中單位時間內的頁面修改量大致相同,并且根據哈希圖方法,統計負載運行過程被修改過頁面的數量后發現,在負載運行一段時間后被修改過的內存頁面數量將達到一定的極值并保持穩定。因此,從圖9的結果中呈現出平均恢復時間大致相同的現象。

圖9 不同負載下的平均故障恢復時間

不同負載下的客戶程序性能影響情況如圖10所示。由圖10可以看出,數據記錄間隔時間為 1 000 ms 時,對客戶程序的影響程度最低。顯然當需要記錄的數據量越大時,數據記錄所消耗的時間也就越多,從而導致退出客戶程序的時間越長,降低客戶程序的執行性能。

圖10 不同負載下的客戶程序性能影響情況

可以得出,引入故障容錯方法必然會對現有的程序帶來一定程度的性能損耗,考慮數據記錄的時間消耗、平均故障恢復時間以及對客戶程序性能造成影響的實驗結果,可以認為當故障容錯方法的數據記錄間隔時間設置為 1 000 ms時,所造成的性能損耗最低。因此,最終選擇1 000 ms作為故障容錯方法的數據記錄間隔時間。

傳統的后拷貝遷移算法在遷移過程中缺乏穩定性,源端虛擬機故障或目標端虛擬機故障都會造成虛擬機狀態的丟失,從而導致遷移失敗。因此本文提出了基于事件同步的故障容錯方法,通過學習現有的虛擬機故障容錯機制,包括檢查點和幀同步。結合兩者的優點,以檢查點為故障恢復起點,并使用幀同步的方式對檢查點間產生的事件進行同步,保障了故障恢復完整性的同時,減少了相關的數據傳輸消耗。最終實現了后拷貝遷移過程中可能發生故障場景的正確恢復。

5 結束語

后拷貝遷移算法是虛擬機動態遷移調度的重要支撐之一,但是目前相關的研究工作還比較少,因此研究如何優化后拷貝遷移算法有重要的實際意義。本文深入研究QEMU-KVM 源代碼,對后拷貝遷移算法展開了研究。分析提煉后拷貝遷移算法存在的穩定性問題,并結合現有文獻資料以及相關領域的研究方法,對其優化思想進行了詳細的闡述,最終針對穩定性問題提出了基于事件同步的故障容錯方法。傳統的后拷貝遷移算法在遷移過程中缺乏穩定性,無論源端虛擬機故障還是目標端虛擬機的故障都會造成虛擬機狀態的丟失,從而導致遷移失敗。因此本文提出了基于事件同步的故障容錯方法,通過學習現有的虛擬機故障容錯機制,包括檢查點和幀同步。結合兩者的優點,以檢查點為故障恢復起點,并使用幀同步的方式對檢查點間產生的事件進行同步,保障了故障恢復完整性的同時,減少了相關的數據傳輸消耗。最終實現了后拷貝遷移過程中可能發生故障場景的正確恢復。

猜你喜歡
頁面故障
微信群聊總是找不到,打開這個開關就好了
大狗熊在睡覺
刷新生活的頁面
保健醫苑(2022年1期)2022-08-30 08:39:14
故障一點通
奔馳R320車ABS、ESP故障燈異常點亮
故障一點通
故障一點通
故障一點通
江淮車故障3例
同一Word文檔 縱橫頁面并存
主站蜘蛛池模板: 在线欧美国产| 五月婷婷导航| 中文字幕66页| 日本三级欧美三级| 亚洲天堂精品在线| 国产精品无码一区二区桃花视频| 色综合中文| 男女男免费视频网站国产| 在线观看热码亚洲av每日更新| 欧美中文字幕第一页线路一| 欧美中文字幕无线码视频| 亚洲天堂视频在线观看免费| 亚洲IV视频免费在线光看| 噜噜噜久久| 99热国产这里只有精品无卡顿"| 农村乱人伦一区二区| 毛片免费观看视频| 欧美一级99在线观看国产| 国产精品部在线观看| 亚洲天堂.com| yjizz国产在线视频网| 直接黄91麻豆网站| 亚洲黄网视频| 99热这里都是国产精品| 国产欧美日韩91| 亚洲精品无码AV电影在线播放| 成人久久18免费网站| 国产成人亚洲综合a∨婷婷| 精品伊人久久久大香线蕉欧美| 国产一区二区在线视频观看| 久草视频精品| 青青极品在线| 国产精品污污在线观看网站| 亚洲A∨无码精品午夜在线观看| 亚洲一区无码在线| 欧美午夜理伦三级在线观看| 怡红院美国分院一区二区| 精品视频91| 午夜国产不卡在线观看视频| 久久国产高潮流白浆免费观看| 91精品国产福利| 欧美日韩亚洲国产主播第一区| 国产在线观看一区二区三区| 国产麻豆va精品视频| 精品成人一区二区| 欧美特级AAAAAA视频免费观看| 91福利国产成人精品导航| 国产精品亚洲片在线va| 在线观看欧美国产| 97国产在线播放| 国产成人精品视频一区视频二区| 国产精品人莉莉成在线播放| 欧美精品1区| 欧美一区二区三区国产精品| 国产www网站| 国产黄网永久免费| 一级不卡毛片| 成人免费一级片| 91亚洲视频下载| 国产成人免费手机在线观看视频| 成人午夜视频网站| 国产喷水视频| 伊人色综合久久天天| 97无码免费人妻超级碰碰碰| 午夜国产在线观看| 欧美一级大片在线观看| 欧美精品亚洲二区| 国产成人精品三级| 97精品伊人久久大香线蕉| 亚洲欧州色色免费AV| 9cao视频精品| 精品人妻一区二区三区蜜桃AⅤ| 亚洲无码37.| 欧美视频在线不卡| 香蕉eeww99国产在线观看| 91欧美亚洲国产五月天| 国产精品视频久| 香蕉视频在线观看www| 亚洲国产成人超福利久久精品| 四虎国产永久在线观看| 免费在线a视频| a级毛片一区二区免费视频|