如果这个问题太笼统,我深感抱歉,但我只是想对我一直在计划的设置进行健全性检查。
目前我有一个在 AWS 服务器上运行的应用程序,SQL 和 IIS 都安装在同一台服务器上,大约有 4 GB 的 RAM。没什么大不了的,我们似乎可以轻松处理大约 100 个并发用户。
我希望扩展到 1000 个并发用户,并引入一些灾难恢复。我正在考虑的设置(请注意,全部在 AWS 中)如下:
- IIS1:IIS 服务器,运行在 Web 场中设置的 Windows 2016
- IIS2:IIS 服务器,运行在 Web 场中设置的 Windows 2016
- SQL1:SQL 服务器,运行 Windows 2016 和 SQL 2016,以 Always on Availability 为主要设置
- SQL2:SQL 服务器,运行 Windows 2016 和 SQL 2016,设置 Always on Availability 作为不可读辅助服务器(用于故障转移)
- SQL3:SQL 服务器,运行 Windows 2016 和 SQL 2016,设置 Always on Availability 作为可读辅助服务器(用于负载平衡)
- DC 这只是一个通用域控制器,用于保持所有相关服务器的链接。此服务器可能还安装了 IIS 负载平衡,或者我可能只需要第三个 IIS 服务器来单独执行此操作。
希望将 SQL 服务器的 RAM 提升至 16 GB,并且可能也为 IIS 服务器设置类似的设置。除非是 Web 场负载平衡器,否则不要指望 DC 上有大量流量。
所以我的主要问题是,这个设置看起来合理吗?我是否遗漏了应该添加的内容?我的想法是,如果这还不够,我可以根据我发现的瓶颈位置,向服务器场添加另一台 IIS 服务器,或者类似于 SQL 服务器的服务器。任何想法都将不胜感激。
答案1
SQL Server 设置有点昂贵。因为您需要可用性组中的 3 个成员,并且您希望将读取任务卸载到辅助节点,这意味着您需要为其中至少 2 个成员授予 SQL Server Enterprise Edition 许可。
我会估算出这个设置的成本,然后与管理层讨论你的RPO 和 RTO 目标(免责声明:我的博客文章与该主题有关。)
一旦您查看了这些 SQL Server 的每月成本,一些更简单的东西(如 Amazon RDS SQL Server)可能更有意义 - 特别是当您确实不需要将读取操作卸载到辅助服务器时。