[AWS]如何將現有EC2完整資訊複製給新EC2使用?

因業務擴展，將在現有AWS基礎上建立新EC2，並將原EC2資料複製給新EC2，以便參考與校正資訊。想確認要如何將舊機器裡的數據資料"完全的複製"到新機器上面去?

可以將舊EC2 在 EBS 快照功能裡，創建出一個新 EBS 卷，然後將這個卷附加到新 EC2 實例，這樣可以達到目的。步驟說明如下：

1. 創建 EBS 快照

首先，登錄到 AWS 管理控制台。進入 EC2 控制台，在左側會看到，選擇Elastic Block Store，點擊指定的EC2後選擇 Create Snapshot（創建快照）。填寫快照的描述，並確認創建。

2. 從 EBS 快照創建新 EBS 卷

在左側Elastic Block Store點擊底下的Snapshot，勾選剛創建的這筆資料，並點擊右邊Actions，指定他選項中的”Create  volume from snapshot”

對話窗中出現volume的相關訊息，可以指定colume type類型，size大小，IOPS，可用區等資訊後，確定後按下”create volume”進行作業。

作業完成後將在左側Elastic Block Store的Volumes找到剛完成的volume。

3. 將新的 EBS 卷附加到新 EC2 實例

完成新 EBS 卷的創建後，你可以將它附加到新 EC2 實例。

在左側Elastic Block Store的Volumes（磁碟） 頁面中選擇剛創建的 EBS 卷。

點擊 Actions（操作），然後選擇 Attach Volume（附加卷）。

選擇要附加的 新 EC2 實例。

點擊 Attach（附加），將卷掛載到新 EC2 實例。

4. 在新 EC2 實例上掛載新 EBS 卷

在新 EC2 上需要手動掛載該 EBS 卷，才能使其可用。以下以LINUX系統為示範：

(1)在使用SSH 登錄到新 EC2 實例後，運用指令 lsblk 或 fdisk -l 命令檢查新附加的 EBS 卷。通常會顯示為 /dev/xvdf 或 /dev/nvme1n1。

(2)在創建一個目標掛載點（例如 /mnt/data）：

sudo mkdir /mnt/data

(3)使用 mount 命令將 EBS 卷掛載到該目錄：

sudo mount /dev/xvdf1 /mnt/data

(4)如果這個 EBS 卷是用來存儲數據，則在掛載後可以開始使用它。

可參考資料

Amazon EBS snapshots - Amazon EBS

Amazon EBS volumes - Amazon EBS

Make an Amazon EBS volume available for use - Amazon EBS

騰訊雲邊緣安全加速平台EO，企業版流量使用與超額費用說明

 

1. 企業版流量是否會用盡？

企業版並無流量用盡的問題，服務會持續運行。

2. 流量顯示為 0 是否會影響使用？

若套餐中無保底流量，顯示的數值會是 0，但不會影響服務的正常使用。

3. 超出保底流量後如何收費？

若套餐有保底流量，右側顯示剩餘流量(如下圖獨立防護流量)；當使用量超過保底部分時，將根據超出部分收取額外費用。

查看方法，可參考下圖

費用相關可參考以下文章:

https://www.tencentcloud.com/zh/document/product/1145/55642?has_map=1

AWS的EC2底層規格與相關問題

 在AWS建立EC2時需要選定EBS 存儲選項，這些類型本身具有不同特性，會影響EC2效能，所以在選擇時應進行了解與審慎選定，以配合未來業務上的規劃與需求。

在 AWS EC2 中，gp2 和 gp3 是兩種不同的 SSD 類型的 EBS 卷（Elastic Block Store）。

    1.若客戶今日設定EC2運用的場景穩定，適合不需要太高配置，可以指定使用gp2。

    2.若設定EC2運用的場景，需要靈活的性能配置、高 IOPS 或高吞吐量的工作負載，
       在設定初期就建議使用gp3。

而在客戶提問：如何將底層gp2 轉換成 gp3格式?

作業前須謹慎評量，並確認先數據備份，並於轉換時進行監控與調整，以應對相關風險。

在AWS EC2相關資訊中，點擊選定要進行變更的EC2，也要再次確認格式為gp2，然後利用Actions -> Modify volume來進行動作(如圖示)

後續會繼續詢問相關規格(如圖)，依次輸入後即可Modify

後續完成動作後，相關設定可按照需求轉變。

另外，從 gp2 轉變(或稱為遷移)到 gp3 是一種簡單且經濟高效的升級。AWS甚至公告，其儲存成本降低了 20%，並且無需額外容量即可提高效能。可參考技術文件鏈結[2]；其他格式可參考技術文件鏈結[3]。以上資訊供大家參考運用。

參考文件

[1]將 Amazon EBS 磁碟區從 gp2 遷移至 gp3

https://docs.aws.amazon.com/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/ebs-migrate-gp2-gp3.html 

[2]https://aws.amazon.com/tw/blogs/storage/migrate-your-amazon-ebs-volumes-from-gp2-to-gp3-and-save-up-to-20-on-costs/

[3]https://aws.amazon.com/tw/ebs/volume-types/

AWS升級服務器後發生磁盤盤符在每次重啟過後變動問題

 客戶詢問AWS升級服務器後，發生磁盤盤符在每次重啟過後會有變動的問題，後續卻又回覆說换uuid就恢復正常，就此狀況分析這個問題成因如下：

通常與磁碟識別和掛載的方式有關。根據描述，客戶升級了 AWS 服務器後，發現每次重啟後磁碟的盤符會變動，後來透過更換 UUID 恢復正常，這意味著問題可能與磁碟識別的持久性和操作系統如何管理磁碟的掛載方式有關。

原磁盤被前系統命名的名稱，舉例來說，通常使用 /dev/sdX 或 /dev/xvdX 的命名方式。這些名稱表示附加到實例的 EBS 卷。而在 AWS EC2 中，設備名稱通常會以 xvda, xvdb, xvdc 等形式顯示，其中 xvda 通常是根磁碟（Root Volume），也就是操作系統安裝所在的磁碟。

但UUID克避免此類問題因為是唯一編號，在 安裝Linux 系統的EC2 上檢視磁碟的 UUID：可以使用 blkid 命令來列出所有掛載的磁碟設備及其對應的 UUID。這會顯示每個磁碟和分區的 UUID。例如：

/dev/xvda1: UUID="1234-5678" TYPE="ext4"

/dev/xvdb1: UUID="8765-4321" TYPE="ext4"

所以此問題就是"前系統所認定的 /dev/sdX 或 /dev/xvdX" 不被新系統認定，而UUID不受影響。

以下是一些可能的原因和分析：

1. 磁碟識別方式的改變

在某些情況下，操作系統會依賴磁碟的 UUID (Universally Unique Identifier) 來識別和掛載磁碟。AWS 中的 EBS 升級或更換磁碟後，可能會導致原有的 UUID 改變，從而造成掛載失敗或盤符變動。

使用 UUID 來掛載磁碟能夠保證即使磁碟的設備名稱（如 /dev/sda）發生變化，操作系統仍然能夠正確識別磁碟並掛載。

2. 磁碟設備名稱變更

AWS 在啟動過程中可能會給 EBS 磁碟分配不同的設備名稱。例如，某次重啟後，磁碟可能被重新分配為 /dev/sdb 而非 /dev/sda。這會導致掛載點變動，尤其是在 /etc/fstab 文件中指定設備名稱的情況下。

如果使用了設備名稱（例如 /dev/sda）而非 UUID 或者 LVM 卷的掛載方式，那麼重啟後磁碟的設備名稱變化會導致掛載問題。

3. AWS 服務器啟動順序或自動掛載配置問題

在某些情況下，操作系統的啟動順序可能會影響磁碟的識別和掛載。特別是在多個磁碟或 EBS 卷的情況下，操作系統可能會錯誤地識別磁碟順序。

如果 /etc/fstab 中指定了磁碟的掛載方式，但磁碟的設備名稱不穩定，可能會導致盤符變動的問題。將掛載方式從設備名稱改為 UUID 或者 LVM 分區，能夠有效避免這些問題。

4. AWS 磁碟重新掛載的問題

在某些情況下，升級後可能會涉及磁碟的重新初始化，尤其是在更換了磁碟或修改了磁碟配置的情況下。這可能會導致某些磁碟的 UUID 更改或設備識別錯誤。

解決方案：

使用 UUID 或 LVM 挂载磁碟： 建議在 /etc/fstab 中使用 UUID 或 LVM 分區來掛載磁碟，而非依賴設備名稱（例如 /dev/sda）。這樣可以確保即使磁碟設備名稱發生變化，掛載仍然不會受到影響。

檢查磁碟 UUID： 使用 blkid 命令可以查看每個磁碟的 UUID。可以通過 lsblk -f 查看每個磁碟的掛載信息及 UUID，並將 /etc/fstab 中的設備名稱替換為對應的 UUID。

檢查 AWS 控制台設置： 確保在 AWS 控制台中，磁碟的配置正確，並且在啟動後沒有發生異常的掛載順序或識別錯誤。

總結來說，這個問題可能是由於升級後磁碟設備名稱的變動導致的識別錯誤，建議使用 UUID 來避免這個問題。