网站数据库如何进行容量规划
在确保有效的数据保护之后，作为一名存储专业人员，容量规划就是第二项重要的职责。规划在前，并且确保应用和服务有足够的资源来运行和成长，不至于碰到天花板，这不仅是重要的，同时也是必需的。将容量和成长空间提前规划为具有足够的可伸缩性的好处是巨大的，不仅对你，对应用也一样，都减小了压力，既能应付应用上出现的非预期的爆炸性增长，也有助于避免资金的非计划性支出。
在确保有效的数据保护之后，作为一名存储专业人员，容量规划就是第二项重要的职责。规划在前，并且确保应用和服务有足够的资源来运行和成长，不至于碰到天花板，这不仅是重要的，同时也是必需的。将容量和成长空间提前规划为具有足够的可伸缩性的好处是巨大的，不仅对你，对应用也一样，都减小了压力，既能应付应用上出现的非预期的爆炸性增长，也有助于避免资金的非计划性支出。
对于我的存储环境，我总是努力维持至少6个月的增长空间。拥有一个合适的容量规划制度，就能够预测资本支出和运维支出，也使得数据中心的空间、电力以及供应链物流的规划更为有效。你最不希望发生的事是凌晨接到电话，说生产负荷已经超出基础架构的性能或容量的能力。这里有个例子，说明容量规划做得多么糟糕。
我工作的公司使用NAS设备存储用户上载的文件，并供用户浏览。NAS设备的容量对于工作负荷来说是合适的，而且也能够将文件异步复制到位于几千英里的辅助NAS设备上。系统能够充裕地存储及提供文件服务，异步复制的延迟也没有超出RPO的要求，而且也能够承受像磁盘损坏及系统重建这样的事情。我们维持着6个月的增长空间，确保容量有充分的缓冲，以便能够消化高流量的冲击和计划中的有机增长。
设备工作正常，就是太贵了。就是因为太贵，所以公司不愿意再买更多的设备了，而且公司了解到，通过创建自己的存储引擎，可以设计一种更为经济的方案。
新的存储引擎是一项令人兴奋的技术，能够以一种非常经济的方式建立可伸缩的应用存储基础架构。它运行在非常便宜的存储设备上，是为存储和提供文件服务的任务而特别设计的，效率很高。花了一年多的时间才完成，存储引擎现在已经完成了编码，并已经在若干综合性的工作负荷下进行了测试。唯一要做的是确保在真实的应用负荷下能够正常工作，并能够在这种规模下正确地存储和提供文件服务。在存储引引擎最后的测试阶段，我们决定以最安全的方式进行推进，即将文件同时存储在新的存储引擎和NAS设备上。一旦我们确信新的存储引擎能够正确地工作，并完全值得信任能够处理进来的文件内容，将不再向AS设备写入文件。
正好在这段时间，公司网站极为火爆，在所有方面都有爆炸性的增长。随着越来越多的人使用我们的网站，向网站上载的文件数也急剧增多。对业务而言非常好，尤其因为我们正在测试的新存储引擎存储文件的成本比NAS方案要低得多。我们已经停止购买新的NAS设备，就指望着存储引擎能够尽快就位。然而不幸的是，一些错误延缓了对新存储引擎信任的确认，而网站人气的增加很快达到了剩余NAS设备的负荷及复制能力的极限。由于没有将购买新的NAS设备纳人流程，我们不得不重新平衡NAS设备的工作负荷，减少异步复制的频率，以增加可用于存储和提供文件服务的资源。而这样一来，就在RPO上造成了缺口。我们的状态很糟糕，一方面NAS设备已经超出了能够充裕运行的范围，另一方面仍然还有源源不断的需求。我们已经停止购买新的NAS设备，指望着能够完全切换到新的存储引擎上，而存储引擎却无法就位。
然后，一个磁盘坏掉了。由于RAID的重建，导致了NAS设备的利用率突然升高，而存储系统已经无法应付生产和复制的工作负荷。我们禁掉了向出现坏磁盘的设备的写入，而让其他系统承担写入负荷。即使这样做了之后，网站建设数据读取的性能仍然受到了影响。更为不幸的是，我们取消了异步复制的作业，这样在第二地点就没有完整的数据集可用了。所以，在受损磁盘的RAID组重建期间，不得不禁掉从中读取数据的操作。幸好，RAID组重建成功，而且数据没有损失。我们从中学到了非常有价值的教训。总是要确保有足够的空间以应对突然的爆炸性增长，以及软件开发方面出现的延迟。假如我们将6个月的增长空间坚持维持到新存储引擎完成生产测试阶段，就能轻松应对这次事件。
当前题目：网站数据库如何进行容量规划
网站链接：http://cdiso.cn/article/shcioh.html
对于我的存储环境，我总是努力维持至少6个月的增长空间。拥有一个合适的容量规划制度，就能够预测资本支出和运维支出，也使得数据中心的空间、电力以及供应链物流的规划更为有效。你最不希望发生的事是凌晨接到电话，说生产负荷已经超出基础架构的性能或容量的能力。这里有个例子，说明容量规划做得多么糟糕。
我工作的公司使用NAS设备存储用户上载的文件，并供用户浏览。NAS设备的容量对于工作负荷来说是合适的，而且也能够将文件异步复制到位于几千英里的辅助NAS设备上。系统能够充裕地存储及提供文件服务，异步复制的延迟也没有超出RPO的要求，而且也能够承受像磁盘损坏及系统重建这样的事情。我们维持着6个月的增长空间，确保容量有充分的缓冲，以便能够消化高流量的冲击和计划中的有机增长。
设备工作正常，就是太贵了。就是因为太贵，所以公司不愿意再买更多的设备了，而且公司了解到，通过创建自己的存储引擎，可以设计一种更为经济的方案。
新的存储引擎是一项令人兴奋的技术，能够以一种非常经济的方式建立可伸缩的应用存储基础架构。它运行在非常便宜的存储设备上，是为存储和提供文件服务的任务而特别设计的，效率很高。花了一年多的时间才完成，存储引擎现在已经完成了编码，并已经在若干综合性的工作负荷下进行了测试。唯一要做的是确保在真实的应用负荷下能够正常工作，并能够在这种规模下正确地存储和提供文件服务。在存储引引擎最后的测试阶段，我们决定以最安全的方式进行推进，即将文件同时存储在新的存储引擎和NAS设备上。一旦我们确信新的存储引擎能够正确地工作，并完全值得信任能够处理进来的文件内容，将不再向AS设备写入文件。
正好在这段时间，公司网站极为火爆，在所有方面都有爆炸性的增长。随着越来越多的人使用我们的网站，向网站上载的文件数也急剧增多。对业务而言非常好，尤其因为我们正在测试的新存储引擎存储文件的成本比NAS方案要低得多。我们已经停止购买新的NAS设备，就指望着存储引擎能够尽快就位。然而不幸的是，一些错误延缓了对新存储引擎信任的确认，而网站人气的增加很快达到了剩余NAS设备的负荷及复制能力的极限。由于没有将购买新的NAS设备纳人流程，我们不得不重新平衡NAS设备的工作负荷，减少异步复制的频率，以增加可用于存储和提供文件服务的资源。而这样一来，就在RPO上造成了缺口。我们的状态很糟糕，一方面NAS设备已经超出了能够充裕运行的范围，另一方面仍然还有源源不断的需求。我们已经停止购买新的NAS设备，指望着能够完全切换到新的存储引擎上，而存储引擎却无法就位。
然后，一个磁盘坏掉了。由于RAID的重建，导致了NAS设备的利用率突然升高，而存储系统已经无法应付生产和复制的工作负荷。我们禁掉了向出现坏磁盘的设备的写入，而让其他系统承担写入负荷。即使这样做了之后，网站建设数据读取的性能仍然受到了影响。更为不幸的是，我们取消了异步复制的作业，这样在第二地点就没有完整的数据集可用了。所以，在受损磁盘的RAID组重建期间，不得不禁掉从中读取数据的操作。幸好，RAID组重建成功，而且数据没有损失。我们从中学到了非常有价值的教训。总是要确保有足够的空间以应对突然的爆炸性增长，以及软件开发方面出现的延迟。假如我们将6个月的增长空间坚持维持到新存储引擎完成生产测试阶段，就能轻松应对这次事件。
当前题目：网站数据库如何进行容量规划
网站链接：http://cdiso.cn/article/shcioh.html
