【问题标题】:DNS Round-Robin on SSLSSL 上的 DNS 循环
【发布时间】:2009-12-12 18:36:13
【问题描述】:

为了实现冗余和负载分担,我们正在添加第二台网络服务器。所有连接都必须使用 SSL,目前无法添加专用设备。

我想使用循环 DNS,其中两台服务器使用不同的 IP 对同一个域进行应答(我们有一个通配符 SSL 证书,所以没关系)。我可以让 DNS 以随机/循环的顺序返回没问题。

在使用 SSL 时这是一个错误的设置吗?

我们的用户模式是一致的——用户将始终使用网络应用程序 8-10 小时。我们希望每个页面视图尽可能快,我担心用户可能会不断在服务器之间切换,可能会否定任何 SSL 握手缓存/保持活动状态。

谢谢!

【问题讨论】:

    标签: ssl dns


    【解决方案1】:

    首先,SSL 能够恢复较早的会话,因此在服务器之间切换每个请求将花费数百毫秒(如果多个客户端同时访问该站点,则更长,因为这是我们正在谈论的 CPU 时间) .

    不过,客户端是否真的会翻转取决于 - DNS“负载平衡”是一项繁琐的工作:

    • 如果您的许多用户使用相同递归名称服务器,他们将获得相同的“第一个 IP”,因此没有负载平衡
    • 如果 DNS 记录具有高 TTL(几个小时),缓存名称服务器将存储特定的 IP 地址排列,直到它们过期(只要您的用户不都使用相同的递归名称服务器就很好)
    • 如果您的用户配置了多个递归域名服务器,如果每个域名服务器都有不同的“第一个 IP”(错误),他们可能会翻转
    • 如果您没有删除“坏”记录的机制并且 TTL 较低,那么如果一台服务器出现故障,50% 的客户端将获得“坏”服务器,并且必须等待超时才能看到您的网站

    正如您所见,根据您更关心冗余/故障转移还是负载平衡,存在各种权衡; DNS 在这里并不是最好的工具 - 您确实需要服务器使用反向代理或 Heartbeat 之类的东西共享 IP(假设您是基于 Linux 的)。

    顺便说一句:如果两台服务器都响应同一个域,那么您不需要通配符证书,但如果您打算在多台服务器上使用证书,CA 通常会收取更多费用。

    【讨论】:

    • 感谢您的信息。这当然不是我们最终的负载平衡解决方案。由于其他子域也是 SSLd,我们已经有一个通配符证书。谢谢!
    【解决方案2】:

    TLDR:你会没事的。 SSL 重新协商不应该频繁发生,以至于最终用户会注意到。

    咆哮从这里开始:

    使用 DNS 进行负载分配是一个经常被误解的话题,它导致了许多轶事证据和稻草人论据。我参加了太多这样的会议。

    我通常是这样解决这些争论的:

    “哇,是的,这听起来真的很通俗[长时间的戏剧性停顿],但它真的不会那么糟糕,因为谷歌使用它”

    $host encrypted.google.com
    encrypted.google.com is an alias for www3.l.google.com.
    www3.l.google.com has address 74.125.224.195
    www3.l.google.com has address 74.125.224.202
    www3.l.google.com has address 74.125.224.193
    www3.l.google.com has address 74.125.224.197
    www3.l.google.com has address 74.125.224.207
    www3.l.google.com has address 74.125.224.206
    www3.l.google.com has address 74.125.224.203
    www3.l.google.com has address 74.125.224.204
    www3.l.google.com has address 74.125.224.196
    www3.l.google.com has address 74.125.224.199
    www3.l.google.com has address 74.125.224.201
    www3.l.google.com has address 74.125.224.194
    www3.l.google.com has address 74.125.224.192
    www3.l.google.com has address 74.125.224.200
    www3.l.google.com has address 74.125.224.205
    www3.l.google.com has address 74.125.224.198
    

    更新:

    这个设置是多余的吗?

    这在工程意义上并不是天生的冗余,因为如果其中一个 ip 发生故障,它将继续为客户提供服务,直到执行 DNS 区域更改并且所有下游缓存都过期。话虽如此,大多数浏览器都足够聪明,可以在这种情况下尝试另一个 ip - reference

    此外,可以很容易地设计一个系统,而不是要求更改 DNS 区域来删除故障节点,而是通过简单的 ip 接管将故障实例的 ip 路由到服务设备。

    这种设置有弹性吗?

    是的,弹性是通过最小化您的故障域来实现的。回到我们的单个 ip 失败示例(请记住,这些 ip 可能代表由数百台服务器甚至整个数据中心支持的负载均衡器)客户点击该 ip 的可能性为 1/16,或约 6%,(使用上面的谷歌示例)。这本质上比具有单个 A 地址的系统更具弹性,这将影响 100% 的用户,或者具有 2 A 记录的系统,其中用户有 50/50 的变化来命中失败的资源。

    【讨论】:

    • 您已证明 Google 使用多个 IP 地址和 DNS 记录进行负载分发。您还没有演示他们如何使用 DNS 实现弹性冗余。提示 - 他们没有!
    • 恕我直言,不是真的。在这种情况下,DNS 的存在只是为了将名称映射到 IP 地址。要使通过该地址到达的 IP 服务真正具有弹性或冗余,需要第 3 层(例如用于广域冗余的 BGP,或用于本地站点冗余的 OSPF ECMP)或第 2 层 (VRRP) 的助手。跨度>
    【解决方案3】:

    别担心。有多个级别的 DNS 缓存,因此用户不会在每次请求时在 2 个 IP 之间切换。每个客户端的 IP 将保持数小时不变。

    我们有一个相反的问题。当服务器宕机时,用户仍然有错误的 IP。我们将 TTL 设置为 1 分钟,但很少有浏览器支持它。由于这个问题,VIP 比 DNS 更适合在同一网络上进行负载平衡。

    【讨论】:

    【解决方案4】:

    DNS 循环不提供冗余

    在没有大量额外帮助的情况下,它只能提供愚蠢的负载共享(注意:不是负载“平衡”,这意味着基于服务器负载的动态负载分配)。

    不过,在两个 IP 上拥有相同的证书应该没问题。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2011-11-04
      • 1970-01-01
      • 2015-04-19
      • 2012-12-28
      • 1970-01-01
      • 2017-04-10
      • 2016-03-24
      • 2018-07-01
      相关资源
      最近更新 更多