设为首页 收藏本站
查看: 1731|回复: 3

[求助] openstack对网络环境的需求

[复制链接]
累计签到:133 天
连续签到:1 天
发表于 2016-6-22 13:36:05 | 显示全部楼层 |阅读模式
大家好
        请问openstack的管理网络和数据网络,一定要万兆吗? 千兆交换机可以吗?有没有官方建议?

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-233796-1-1.html 上篇帖子: openstack 错误集锦 下篇帖子: OpenStack的手动安装 网络

尚未签到

发表于 2016-6-22 14:07:29 | 显示全部楼层
对外提供服务,并不建议千兆
如果只是内部的管理,局域网的控制。并不涉及大量客户访问的一端,是可以尝试千兆的。
因为管理部分,部分情况下。对带宽需求并不十分迫切

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

尚未签到

发表于 2016-6-22 14:09:37 | 显示全部楼层
相关参考:http://www.openstack.cn/?cat=352
网络建议的总结

OpenStack has complex networking requirements for several reasons. Many components interact at different levels of the system stack that adds complexity. Data flows are complex. Data in an OpenStack cloud moves both between instances across the network (also known as East-West), as well as in and out of the system (also known as North-South). Physical server nodes have network requirements that are independent of instance network requirements, which you must isolate from the core network to account for scalability. We recommend functionally separating the networks for security purposes and tuning performance through traffic shaping.

You must consider a number of important general technical and business factors when planning and designing an OpenStack network. They include:

对厂商独立性的需要。要避免硬件或者软件的厂商选择受到限制,设计不应该依赖于某个厂商的路由或者交换机的独特特性。

对于大规模地扩展生态系统以满足百万级别终端用户的需要。

对于支持不确定的平台和应用的要求。

对于实现低成本运营以便获益于大规模扩展的设计的需要。

对于保证整个云生态系统中没有单点故障的需要。

对于实现高可用架构以满足客户服务等级协议(SLA)需求的要求。

对于容忍机柜级别的故障的要求。

对于最大化灵活性以便构架出未来的生产环境的要求。

Bearing in mind these considerations, we recommend the following:

Layer-3 designs are preferable to layer-2 architectures.

设计一个密集的多路径网络核心以支持多个方向的扩展和确保灵活性。

使用具有层次结构的地址分配机制,因为这是扩展网络生态环境的唯一可行选项。

使用虚拟联网将实例服务网络流量从管理及内部网络流量中隔离出来。

使用封装技术隔离虚拟网络。

使用流量整形工具调整网络性能。

使用 eBGP 连接至因特网上行链路。

在三层网络上使用 iBGP 将内部网络流量扁平化。

确定块存储网络的最高效配置。


另:可参考http://docs.openstack.org/zh_CN/ ... -network-focus.html

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

累计签到:152 天
连续签到:1 天
发表于 2016-6-22 14:19:46 | 显示全部楼层
可以参考架构的设计
如果你的客户量很大,千兆是个不明智的选择。
如果只是内部管理网络,千兆是可以谨慎考虑的选择。

http://docs.openstack.org/zh_CN/ ... are-selections.html
网络硬件选择

选择网络硬件主要考虑应包括:

端口数目
用户将会对网络设备有充足的端口数有需求。

端口密度
网络的设计会受到物理空间的影响,需要提供足够的端口数。一个占用1U机柜空间的可提供48个 10GbE端口的交换机,显而易见的要比占用2U机柜空间的仅提供24个 10GbE端口的交换机有着更高的端口密度。高端口密度是首先选择的,因为其可以为计算和存储省下机柜空间。这也会引起人们的思考,容错的情况呢?电力密度?高密度的交换机更加的昂贵,也应该被考虑使用,但是没有必要覆盖设计中所有的网络,要视实际情况而定。

端口速度
网络硬件必须支持常见的网络速度,例如:1GbE、10GbE 或者 40GbE(甚至是 100GbE)。

冗余
网络硬件冗余级别需求会被用户对高可用和开销的考虑所影响。网络冗余可以是增加双电力供应也可以是结对的交换机。

[注意]        注意
如果这是必须的,那么对应的服务器硬件就需要配置以支持冗余的情况。用户的需求也是决定是否采用全冗余网络基础设施的关键。

电力要求
Ensure that the physical data center provides the necessary power for the selected network hardware. This is not an issue for top of rack (ToR) switches, but may be an issue for spine switches in a leaf and spine fabric, or end of row (EoR) switches.

协议支持
使用特定的网络技术如RDMA,SRP,iSER或SCST来提高单个存储系统的性能是可能,但是讨论这些技术已经超出了本书的范围。

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表