服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

使用CloudFront进行蓝/绿部署

我正在寻找使用CloudFront进行蓝/绿部署的方法。 有没有人有从一个CloudFront分配到另一个的好的解决scheme,或者每个人真的只是创build他们的分布,然后再也不会碰它了吗? 我的CloudFront发行包含一个用于静态内容的S3 来源 (javascript等)和一个指向AWS ELB的自定义来源。 没有更改为CloudFront 在正常情况下,我们根本不会对CloudFront分配进行任何更改。 我们通过在S3中更改静态内容文件的名称来在S3源中对我们的静态内容进行版本化,并在Elastic Load Balancer(ELB)下将部署滚动到EC2实例。 但是,有时我们需要对CloudFront分配本身进行testing和更改,或者对环境进行了足够大的更改,因此我们需要在新环境中指向新的ELB。 两个CloudFront分配 我尝试的第一个select是有两个单独的CloudFront Web分配 ,一个用于当前的或A环境,另一个用于我的新环境或B环境。 我尝试使用Route53 加权路由策略 ,其中为我的www.domain.com Route53logging添加了两条logging,一条指向CloudFront Distribution A,权重为1,另一条指向CloudFront Distribution B,权重为0.计划是在我想从分发A转移到分发B时更改权重。但是,一次只能有一个CloudFront分发注册www.domain.com 备用域名(CNAME),否则会出现以下错误: com.amazonaws.services.cloudfront.model.CNAMEAlreadyExistsException: One or more of the CNAMEs you provided are already associated with a different resource. (Service: AmazonCloudFront; Status Code: 409; Error Code: CNAMEAlreadyExists; Request ID: ef84a5f0-44e7-11e5-9315-0ba167bb108a) 一个CloudFront分配 第二个选项是保留一个CloudFront Web分配。 […]

在光纤通道结构上正确放置设备

我们正在为我们的光纤通道架构获得一对新的8Gb交换机。 这是一件好事,因为我们的主要数据中心的端口已经用完了,而且至less可以让我们在两个数据中心之间运行至less一个8Gb ISL。 我们的两个数据中心距离光纤运行约3.2公里。 几年来,我们已经获得了稳定的4Gb服务,并且我也抱有很高的期望,能够支持8Gb。 我目前正在弄清楚如何重新configuration​​我们的结构来接受这些新的交换机。 由于几年前的成本决定,我们没有运行完全独立的双环路结构。 完全冗余的成本被认为比交换机故障的不太可能的停机时间更昂贵。 那个决定是在我的时代之前做出的,从那以后事情没有多大改善。 面对交换机故障(或FabricOS升级),我想借此机会使我们的结构更具弹性。 以下是我正在考虑的布局图。 蓝色的项目是新的,红色的项目是现有的链接,将(重新)移动。 FibreChannel digram http://sysadmin1138.net/images/fabric-option.png 红色箭头线是当前的ISL交换机链路,两个ISL来自同一个交换机。 EVA6100目前连接到两个具有ISL的16/4交换机。 新的交换机将允许我们在远程DC中有两个交换机,其中一个远程ISL正在移动到新交换机。 这样做的好处是,每台交换机与另一台交换机的距离不超过2跳,两个EVA-复制关系的EVA4400之间相距1跳。 图表中的EVA6100是一个较旧的设备,最终会被replace,可能还有另外一台EVA4400。 图表的下半部分是我们大部分服务器的地方,我对于确切的位置有一些担忧。 有什么需要去那里: 10台VMWare ESX4.1主机 访问EVA6100上的资源 一个故障转移群集(文件服务器群集)中的4台Windows Server 2008服务器 访问EVA6100和远程EVA4400上的资源 2个Windows Server 2008服务器位于第二个故障切换群集(Blackboard内容) 访问EVA6100上的资源 2个MS-SQL数据库服务器 访问EVA6100上的资源,夜间DB导出到EVA4400 1个带有2个LTO4磁带机的LTO4磁带库。 每个驱动器都有自己的光纤端口。 备份服务器(不在此列表中)后台处理 目前,ESX集群可以容忍多达3个,也许4个主机closures,然后再开始closures虚拟机。 令人高兴的是,一切都有MPIO打开。 目前的4Gb ISL链路还没有接近饱和,我注意到了。 这可能会改变两个EVA4400的复制,但至less有一个ISL将是8Gb。 看看我从EVA4400-AI中获得的性能,我很确定,即使有复制stream量,我们也很难跨越4Gb线路。 4节点文件服务集群在SAN1SW4上可以有两个节点,在SAN1SW1上可以有两个节点,因为这会使两个存储arrays都跳一跳。 10个ESX节点我有点头疼。 在SAN1SW4上有三个,在SAN1SW2上有三个,在SAN1SW1上有四个,是一种select,我很乐意听到关于布局的其他意见。 其中大部分都具有双端口FC卡,所以我可以双重运行几个节点。 不是所有的 ,但足以让一个单一的交换机失败,而不是所有的一切。 两个MS-SQL盒子需要在SAN1SW3和SAN1SW2上,因为它们需要靠近主存储器,而db-export性能不那么重要。 LTO4驱动器目前位于SW2上,距离其主拖缆2跳,所以我已经知道这是如何工作的。 那些可以留在SW2和SW3。 我不希望将图表的下半部分作为完全连接的拓扑,因为这会将我们的可用端口数从66减less到62,而SAN1SW1将是25%的ISL。 但如果强烈build议我可以走这条路。 […]