- Why Edgenexus?
- Try
- Products
- Solutions
- Applications
- Resources
COMPARE
READ
WATCH
SEE
Alliances and Partners
- Support
负载平衡器/ADC ALB-X 试运行教程
（ADC 应用交付控制器）
在此进行试驾
目录
我们希望您能享受 ALB-X 负载均衡器带来的体验，并希望您能使用实际配置。
-
作为试运行的一部分，我们已预先配置了一些示例服务，以便您可以开始运行。
-
我们将此设置托管在 Azure 上，但不用担心，您不需要拥有 Azure 账户，而且是免费的。
-
欢迎重新配置设备，在自己的服务器上试用。
以下几句话可以帮助您浏览用户界面，并从试驾中获得最大收益，请系好安全带....。
注册 ALB-X 试运行后，您将获得自己的唯一 URL，以便通过网络浏览器访问 ALB-X GUI。 如果可能，我们建议使用谷歌 Chrome 浏览器。
- 请注意，访问图形用户界面使用的是一个非标准端口：27376，这样标准 HTTPS 端口：443 就可以作为负载平衡服务进行分配。
- 如果出现 SSL 安全警告，请不要担心，这是因为管理连接默认使用本地证书进行加密。
对于实时部署，您可以自由上传自己的证书，以确认管理连接的真实性。
出现提示时，请输入本次试运行会话的唯一用户名和密码（已通过电子邮件发送给您）。
Azure 试运行设置
- Azure 使用 1:1 NAT 端口映射，提供从互联网公共 IP 地址空间到内部专用 IP 地址的访问。
-
负载平衡器设备上自动配置的 IP 地址使用 Azure 私有 IP 地址。
-
当然，你可以配置 Azure 为其他服务打开和 NAT 更多端口。
-
本演示只开放了 80、443 和 27376 端口（用于图形用户界面）。
ALB-X 试运行预填充服务
为了进行测试，我们在两个公开的网络服务器上提供了真实的服务器内容：
- ALB-X 可以使用 DNS 将名称解析为公共 IP 地址。 每个网站都有文字/图片显示哪个网站提供了内容，这样你就能看到负载平衡过程的运行情况。
我们为您设置了 4 项演示服务：
|
姓名
|
港口
|
无障碍环境
|
|---|---|---|
|
HTTP 最少连接负载平衡
|
80
|
http://yoururl
|
|
HTTPS 卸载
|
443
|
https://yoururl
|
|
基于 Cookie 的持久性
|
601
|
http://yoururl/601/
|
|
身体测试重写
|
602
|
http://yoururl/?602
|
80 端口服务 - HTTP 最少连接负载平衡
第一个服务是一个基本的 80 端口网络服务器负载平衡器，使用我们的 "最少连接 "负载平衡策略，连接 2 个 "真实服务器"。
- 使用浏览器打开与 ALB-X 管理访问所用公共 IP 地址相同的 HTTP 连接，您应该会收到与下面类似的返回信息。
端口 443 上的服务 - SSL 卸载
第二个服务端口为 443。 在这种情况下，负载平衡器进行加密，有时也称为 SSL "卸载"。
- 我们在试运行演示中使用了默认 SSL 证书，因此您在连接该频道时，浏览器中会出现相同的安全警报。
请随时上传自己的 SSL 证书并将其应用于服务，请参阅稍后的说明。 点击安全例外后，您将在浏览器中看到相同的内容。
HTTP 转 HTTPS 重定向
我们首先可以看看使用flightPATH 的 HTTP 到 HTTPS 重定向。
该功能通常用于确保网络流量通过安全连接提供。
- 我们预先配置了 flightPATH 规则，并将其应用于 80 端口 HTTP 通道，以查找查询字符串为/?安全
/?secure
如果 flightPATH 发现这种 "情况"，它将对流量采取行动，并向浏览器返回 302 重定向，告诉浏览器向 HTTPS://your.original.request.location 执行另一个 GET 请求，在这种情况下，该请求将与服务的公共 IP 地址相同，但使用 443 通道。
您现在不妨看看 flightPATH 规则是如何配置的。
点击左侧的 "库 "选项卡，选择 flightPATH 即可。
点击"Force HTTPS - when query string is secure（强制 HTTPS - 当查询字符串是安全的 ）"条目，你可以看到
- "条件 "是查询字符串是否包含安全信息
或
- "操作 "为重定向 302 https://$host$$path$$querystring$（$ 是有用的变量，可用于规则操作中）
基于路径的 Cookie 持久性和使用服务器
- 记住：网页中的所有对象（如图片、视频、JS）都需要向网络服务器发出单独的 GET 请求。 这种行为可能与应用程序不兼容，应用程序可能需要 "持久性 "或 "粘性"。
对于 HTTP 服务，可以通过应用特殊的会话 Cookie 来实现，浏览器会在随后对该服务的所有请求中显示该 Cookie，通常会在 "会话 "期间显示。
- 为了演示这一点，我们为基于 ALB 会话 cookie 的负载平衡配置了 "内部 "601 服务。 正如我们所说，由于 601 服务无法从 Azure 网络外部直接访问，因此我们使用了 flightPATH 规则将流量导向该服务。
flightPATH 规则会查看请求的路径，如果是 /601/，就会将流量发送到运行在 601 端口的服务。 以下是该 flightPATH 规则的详细信息。
flightPATH 规则显示了如何根据路径将流量发送到另一个服务，这是流量操纵或内容引导的强大工具。
我们可以看到 VIP 在 601 端口上的配置：
- 现在尝试将 /601/ 路径添加到公共 IP"http://myurl/601/"，应该会得到如下结果：
http://myurl/601/
您可以看到这里的所有内容都是从服务器 1提供的--您可以查看浏览器的开发工具，您会看到一个名为jnAccel=的 cookie 已被设置。
路径重写和 RegEx 评估
由于真实服务器的/601/ 路径下没有任何内容，我们需要将其从请求中移除，否则会出现404 错误 （我们也可以使用 flightPATH 隐藏该错误 ）。
- 为此，我们对运行在 601 端口的服务应用了另一条名为 "移除路径 601 "的 flightPATH 规则。
在这里，我们再次将路径中的 601 作为触发该规则的条件。
- 在本例中，我们使用了 "评估 "函数，该函数使用正则表达式，通过操作现有的系统变量（在本例中是我们看到的原始路径值）来创建新变量。
因此，我们只需提取路径前缀 /601/ 后面的数据即可创建 NewPath。
操作"是使用$NewPath1$和$querystring$重写路径（如果有的话）。
HTML 正文替换
在另一个使用端口:602 的服务示例中，我们展示了如何操作 HTML 内容，而不仅仅是 HTTP 标头。
- 我们使用了查询字符串/?602，而不是使用路径来引导 80 端口的流量使用 602 服务。 - "http://myurl/?602"
http://myurl/?602
如果在浏览器中输入试运行的 ALB-X 的公共 IP 地址并添加/?602， 应该会返回以下结果。
您可以看到一行橙色的附加文字说明--"......"。
- "此文本由 flightPATH 添加"
这是通过 2 条 flightPATH 规则实现的。
应用于端口：80 的以下规则会查找查询字符串值 602，并将所有匹配请求发送到运行在端口 602 上的服务。
在端口 :602 上运行的服务应用了 flightPATH 规则，该规则执行 "正文最后替换 "功能，查找关闭的正文标记
</body>
而代之以
<font face=’Arial’ size=’6′ color=’orange’><center>This text has been added by flightPATH</center></font></body>
在这种情况下，不需要任何条件或评估，因此该功能将适用于通过该服务的所有流量。
希望您能看到如何将这些设施结合起来，执行一些巧妙的 HTTP 流量操作，而这些只是 flightPATH 功能的冰山一角。
请您亲自尝试一下，我们很乐意了解您的具体要求。
真实服务器健康检查
接下来我们要了解的是真正的服务器健康检查。 至关重要的是，要对服务进行正确类型的健康检查，以便可靠地检测后端服务器的健康状况，确保客户端流量只被发送到正常运行的服务器上。
创建新服务时，我们必须定义一组默认参数。 对于服务器监控，我们使用 TCP 连接健康检查。 服务器监控 "选项位于所配置服务的 "基本 "选项卡下。
虽然这是一个合理的起点，但我们强烈建议配置更可靠的健康检查并将其应用于服务。
- 健康检查可在 "库/真实服务器监控器 "下找到。
在测试驱动中，我们添加了第三个真实服务器监控器，以显示 HTTP 响应健康检查的示例。
HTTP 200 OK 监控方法
200OK 使用 HTTP GET 请求到为检查配置的页面位置，并确保返回 200OK 状态响应。
它不会查找任何特定内容，只是检查端口上是否有网络服务器在运行，并能提供所请求的页面。
- 这是比 TCP 连接更好的监控器，因为它在第 7 层运行，检查应用程序是否在运行，但不会检查返回内容的特定响应。
如上图所示，我们已将此监控器应用于运行在 601 端口的服务。
HTTP 响应监控方法
测试驱动中配置的 NLS 监视器使用 HTTP 响应检查。
为此，您需要定义具体的页面位置（在需要主机标头的情况下，可以是完整的 URL），并定义应出现在服务器/应用程序返回数据中的内容（文本字符串）。
这是一种更好的测试方法，因为页面必须存在，具体内容必须可用。
- 如果应用程序面对的是后端数据库，那么最好让健康检查页面上的内容检索状态取决于数据库的实时响应，而不仅仅是网络前端服务器上的静态内容。
您可以看到，我们已将此监视器应用于运行在端口 602 上的服务。
您可以修改此健康检查的 "必填内容 "字段中的文本，然后您就会看到服务器变红，表明它们没有通过健康检查。 将所需内容还原为正确值，服务器就会恢复绿色。
监测间隔
在 "高级 "选项卡下，您可以设置对该服务进行健康检查的频率和超时时间等。
在试车时，我们将监控间隔设置为 3 秒，超时 2 秒。
监控失效计数设置为 3，因此在标记服务器不可达之前必须连续收到 3 个响应。
- 当监控进入计数为 2 时，必须有连续 2 次成功响应才能标记服务器恢复服务。 在大多数情况下，这些都是合理的值。
HTTPS 和 SSL 证书
越来越多的网站开始使用 HTTPS，到 2017 年初，使用 HTTPS 的比例已经有所上升。
大多数企业应用程序都需要加密保护，因此可以肯定的是，您将需要在 ALB-X 上使用证书，而部署 HTTPS 负载平衡器是确保访问非加密应用程序安全的一种快速而简单的方法。
- ALB-X 默认安装了一个名为 "default "的私人证书，用于与管理图形用户界面进行 HTTPS 连接。 我们已将此证书应用于虚拟服务或客户端的 Test Drive :443 HTTPS 配置服务。
服务配置为 SSL 卸载，因此真实服务器端配置为无 SSL。
证书上传/导入
您可以使用 "库 "部分的 "SSL 证书 "菜单将自己签名的证书上传到 ALB-X。
正如文本输入框中强调的那样，证书必须是 PKCS#12 格式，才能导入 ALB-X。
- 这种类型的证书包含私人密钥，并有密码保护，在导入时需要输入密码。
您在导入时赋予证书的名称（不得包含空格）将出现在 IP 服务 "基本 "选项卡的证书选择下拉菜单中。
真实服务器再加密
如果真实服务器需要 SSL/TLS 重新加密，最明智的选择是从真实服务器 SSL 证书下拉菜单中选择 "任意"。
- 这意味着 ALB-X 将接受真实服务器提供的任何有效证书。
SNI（服务器名称指示）
由于公共 IP 地址稀缺，而且在 Azure 中只能配置一个 VIP，因此能够通过一个虚拟服务支持多个安全域/主机 URL 是非常有用的，而这在 ALB-X 上是可以实现的，因为我们支持 SNI。
- 要使用 SNI，只需从虚拟服务 SSL 证书下拉框中选择所有必要的证书。 每次点击都会切换选择或取消选择证书作为 SNI 列表的一部分。
在真实服务器端，如果服务被重新加密并托管在普通服务器上，它们将需要 SNI 以进行正确的服务识别和协商，因此 SNI 应被选为真实服务器 SSL 证书下拉菜单中的选项。
认证
ALB-X 支持与 MS AD（微软活动目录）/ LDAP 服务器结合使用的预认证。
- 如果您能访问可公开访问的 MS AD / LDAP 服务器（使用 LDAP），您可以自由探索此功能。 在线 ALB-X 用户指南会指导如何配置该功能。
该功能是已停产的微软 TMG 产品的常用替代品。
设备使用和连接监控
菜单的视图部分为您提供了实时（状态）或随时间变化趋势（历史）查看连接状态和实际服务器健康状况的方法。
- 您还可以在这里找到 W3C 和系统日志。 您还可以创建自己的自定义部件，在仪表板上显示。 我们鼓励您查看本节中的各种选项。
系统
在这里，您可以找到适用于系统功能的配置选项，如设置时间和日期、启用电子邮件警报、许可产品、选择记录方式和日志发送位置、重启和重新启动设备、配置 SNMP 和添加其他管理用户等。
高级
在高级菜单中，您可以备份和恢复配置，也可以上传 jetPACK 模板配置。
- 您可以修改常见的 HTTP 协议行为，还可以执行软件升级并从云库下载其他软件包。
最后是故障排除部分，在这里我们可以轻松下载捆绑的支持文件包、执行网络 PING 以及执行各种系统跟踪和网络数据包捕获。
谢谢。
- 我们衷心希望您享受 ALB-X 的试驾体验。
如果您有任何问题，pre-sales@edgenexus.io。
版权所有 © 2021 Edgenexus Limited。