使用 Wowza 和 AWS 的 HTTPS 流和動態負載均衡器
我們正在使用
Wowza實例在基礎架構上執行實時流式傳輸AWS。我們有一個腳本，用於監控負載均衡器，並根據每個邊緣伺服器的連接/查看器數量在需要時啟動/終止實例。它非常適合HTTP/RTMP/RTMPT流式傳輸。我們現在正在嘗試為HTTPS流式傳輸實現動態負載平衡並自動化擴展過程。我們的主要問題是如何以最好的方式自動化它？我們不知道將要啟動的邊緣伺服器的 IP，因此無法提前創建 DNS 記錄。一種可能的解決方案是保留一些彈性 IP（即 20 個）和相同數量的 DNS 名稱，並在擴展期間使用它們。但這將限制我們可以動態啟動的伺服器數量。
我們可以嘗試實施更優雅的解決方案嗎？
我們的 LB 基礎設施在裡面
AWS VPC，我們有一個可以使用的星級證書。此外，Wowza Load Balancer僅用於告訴查看者可用邊緣伺服器的 IP。之後，查看器直接連接到邊緣伺服器。
您可以配置實例以在啟動時發現其身份，例如通過在實例標籤中或通過實例元數據傳遞實例所需的 Internet 主機名，並讓每個節點向 Route 53 發送 API 請求以配置其自己的 A 記錄，本質上在啟動時聲明其 Internet 身份。它可以發送第二個請求以在正常關閉時刪除該記錄。
這是我在現場實例中使用的一種機制。
由於您提到您的域不在 Route 53 中，因此您需要一個解決方法，除非您可以將整個 DNS 託管移動到 Route 53，除了政治/企業反對之外沒有理由不這樣做。當然，您可以在目前註冊商處保留您的域註冊，並且只需使用 Route 53 來託管DNS。
以下是一些可能的解決方法：
您可以獲取一個新域名並將其放在 Route 53 中。這裡的缺點是您需要一個新證書。
您可以創建域的子域，將子域委派給帶有
NS記錄的基礎 diamond 的 DNS 伺服器中的 Route 53，但您仍然需要一個新證書，因為該*.example.com證書僅對一級主機名有效：foo.example.com按預期工作，但foo.bar.example.com沒有。這將需要*.bar.example.com.因此，這兩種選擇都需要新證書。
另一種選擇是使用Let’s Encrypt並讓每台伺服器在啟動時以程式方式為自己獲取免費的 SSL 證書。這將允許您使用任何域或子域，而無需額外的證書費用。
最後，您可以使用一些 DNS 黑客技術。這對某些人來說似乎違反直覺，但由於 Route 53 是一個僅權威（非遞歸）的 DNS 服務，它可以按預期工作。
在 Route 53 中為您的現有域創建一個託管區域。這是有效的，即使您的 DNS 不是由 Route 53 託管的。
託管區域將分配 4 個名稱伺服器，通常採用以下格式：
ns-aaaa.awsdns-bb.com. ns-cccc.awsdns-dd.net. ns-eeee.awsdns-ff.org. nd-gggg.awsdns-hh.co.uk.a、b、c 等是系統分配的數字。
獲取這些記錄，並使用它們將現有 DNS 伺服器中的特定主機名委託給 Route 53。
media-100 IN NS ns-aaaa.awsdns-bb.com. media-100 IN NS ns-cccc.awsdns-dd.net.對於分配的四個 AWS DNS 伺服器中的每一個，對每個“池”主機名重複該過程。從某種意義上說，這仍然有些限制，因為它將您的池限制在有限的大小，但與保留的彈性 IP 解決方案不同，這種方法沒有硬維護成本（彈性 IP 地址的每個地址每小時收費 0.005 美元）未被用作正在執行的實例的主要彈性 IP）。
當然，您的主要 DNS 服務可能支持萬用字元，在這種情況下，您只需要一組記錄：
media-* IN NS ns-aaaa.awsdns-bb.com ; etc., one for each of the 4 hostnames.這些 NS 記錄通過將這些主機名中的每一個的解析委派給 Route 53 來工作。由於 Internet 上的任何內容都沒有配置為向您域中的任何其他主機名的那些特定 4 Route 53 名稱伺服器發送請求，因此 Route 53 沒有不知道您的整個區域不會破壞任何東西。
一個潛在的常見誤解是，一個域只能在 Route 53 中配置一次……但實際上，您可以在相同甚至不同的 AWS 賬戶中為完全相同的域名擁有多個託管區域，因為其中的每一個託管區域將由 Route 53 到該區域的特定 4 個名稱伺服器應答…因此，即使您後來將整個 DNS 移動到 Route 53，如果您將另一個區域從其他 DNS 提供商複製到一個Route 53 中的新託管區域並使其具有權威性，因此此解決方案不會出現衝突。