希望有人能帮助！ 目前正在计划从Azure服务pipe理器迁移到Azure资源pipe理器。 无法find任何文件，并认为我会伸出援手。 使用Move-AzureVirtualNetwork的方法将虚拟机从ASM迁移到ARM时。 如果SQL Alwayson群集是该虚拟networking中唯一的可用性集合。 迁移时是否对集群有影响？ 如果是这样，修复是完全重新configuration和重新部署群集？ 谢谢，拉奇
据我所知Azure没有内部服务的负载平衡器，内部端点没有负载平衡。 但是，有人可以实施一个“软”解决scheme，或者可以build议我一些有用的文章阅读？ 多谢
假设我有一个域，foo.com，我有一系列的页面，如foo.com/123和foo.com/456等。我想使用该域，并提供没有www前缀的链接。 这些页面也将链接到其他页面（和彼此）没有www前缀。 我正在使用Azure来托pipe我们的网站，这与EC2相同，因为服务器环境是虚拟化的，所以域不能有Alogging。 因此，微软和亚马逊都会告诉你使用CNAMElogging来将你的域名指向他们pipe理的Alogging。 在Azure的情况下，我的CNAMElogging指向一个cloudapp.netlogging（由微软pipe理）： foo.com CNAME foo.cloudapp.net 其中foo.cloudapp.net是我在Azure上设置的域。 我遇到各种各样的问题，如电子邮件传递和各种人无法加载该网站的各种问题。 2个不同的名称服务器提供商，我的主机告诉我，它违反了RFC有一个根域是CNAME条目，这就是为什么我的问题是零星的。 听到这个消息，我感到很惊讶，因为现在你看到这么多的网站托pipe在EC2或Azure上，并且不使用www前缀。 这些网站如何设置，以便他们可以只使用foo.com （没有www前缀）？ 更新：当我问到有关EC2或Azure的问题时，我正在专门查找有关Azure的信息。
我们有许多用于.NET和Java开发和QA的Windows Server虚拟机。 我发现Azure有吸引力的原因很明显，但主要是为了减less在环境维护上花费非生产时间的机会。 在function上，在清理了一些应用程序（许可等）的系统ID问题之后，一切都很好，但是性能有些不足： 在Hyper-V或ESXi上运行时，我们的系统需要花费大约2分钟的时间来构build解决scheme，但Azure A3计算机最多需要花费12分钟来完成相同的构build 。 资源监视器显示大部分时间机器处于IO等待读取磁盘的状态。 有什么我应该做的不同，或者我应该期望在所有情况下本地机器更好的performance？
有没有办法将Azure Active Directory中的用户用作Azure虚拟机的用户？ 分别是，有没有办法为Azure虚拟机创build多个用户帐户？
所以我们的虚拟机已经坏掉了（它实际上是一个Azure中的Linux机器），我们在这个虚拟机上运行一个4个磁盘的RAID10arrays。 这是一个Ubuntu的盒子。 从我可以告诉四个数据磁盘是好的，这只是虚拟机被拧紧。 现在，我可以从该机器上分离磁盘并创build一个新的Linux实例，然后将这些磁盘附加到该新实例。 问题是，如何让mdadm使用这些磁盘上的数据设置RAID10arrays（我不希望它作为新驱动器被擦除）。 另外，这是否按照什么顺序我附加磁盘或将mdadm找出哪个磁盘是哪个数组？
我有一台虚拟机，我们称之为Ceres，它目前在Azure中运行。 我想有两份Ceres正在运行。 是否可以简单地在Azure中创build另一个相同的服务器实例？ 我注意到在Microsoft Azure的参考文献“多个实例”，但我找不到一个简单的方法来启动同一个服务器的两个实例。 相关虚拟机正在运行Windows Server 2012 R2。
当Windows Server（2012或-R2）从Azure中的Stopped + Deallocated状态返回时，“您是否希望在此networking上findPC，设备和内容，并自动连接到打印机和电视机等设备？出现： 问题一再出现，因为Windows创build新的networkingconfiguration文件，我想Azure感觉有新的networking适配器：经过几个星期的定期closures/打开周期列出的（只有一个）networking适配器被命名为“以太网89 “和networkingconfiguration文件被命名为”networking19“ – 请注意数字。 我发现这个问题迄今为止的解决schemebuild议设置networkingconfiguration文件的公共/私有属性，这是没有帮助的，因为它是每次新的networkingconfiguration文件。 其他人build议closures域configuration文件中的networking发现，但我没有这样的： 上述设置不会阻止Windows显示每个新的networkingconfiguration文件的问题。 我必须避免这个提示，因为它从一个即将在这个服务器上启动和自动化的GUI程序窃取焦点。 如何禁用有关新networking的这个问题？
我们正在将一些虚拟机和云服务迁移到Azure，但是我们需要这些服务来连接到我们的合作伙伴的AD。 我是一个开发人员，而不是一个系统pipe理员，所以我不知道如何做到这一点，或者甚至是可能的。 从我的理解，我们将需要做这样的事情： 在Azure中设置虚拟networking 在Azure和合作伙伴的数据中心之间build立站点到站点的VPN 在Azure中设置Cloud Services / VM（在＃1的VNet中） 在Azure AD中build立一个域，比方说我们称之为“AzureDomain” 在Azure AD域和我们的合作伙伴的AD域（“PartnerDomain”）之间build立信任关系。 在Azure云服务/虚拟机中设置Windows服务/ IIS AppPools以在Azure AD域中的帐户下运行，例如“AzureDomain \ service_account” 将合作伙伴授予权限给“AzureDomain \ service_account”以访问它所需的任何networking共享/数据库/等资源。 我有没有错过任何步骤？ 例如，是否需要某种types的AD同步，AzureDomain =>合作伙伴的DC或PartnerDomain => Azure DC？ 我不关心Azure基础架构中的服务在Azure AD中的帐户下运行，还是在合作伙伴的AD中运行。 我只想要最简单的解决scheme，它将允许Azure中的服务访问合作伙伴数据中心中的资源。
我们正在与微软Azure支持团队进行一场战斗。 我希望Serverfault社区能够支持，因为以前的支持团队已经搞砸了我们。 这是发生了什么事。 作为我们在Azure上托pipe的一个更大的SaaS服务的一部分，我们有一个接受基本HTTP请求的前端应用程序服务，执行一些小的validation，然后将繁重的工作传递给后端服务器。 这个过程不是CPU，内存或networking密集型的，我们根本不接触磁盘子系统。 定价层级是“基本：2中等”，这对我们所承受的负担来说已经足够了。 CPU和内存图表显示系统在很大程度上处于内存使用率的36％左右。 由于我们在服务器学校备受关注，我们使用Azure的标准监控设施主动监控整个解决scheme的各个层面。 我们跟踪的其中一个计数器是“磁盘队列长度”，它是Azure应用服务中可用的极less数计数器之一，因此它必须非常重要。 回到服务器学校，我们被告知，磁盘队列长度理想情况下应该为零，如果它持续超过1，你需要一起行动（某些RAIDconfiguration有一些例外）。 过去几年一切顺利，磁盘队列长度为99％，而当微软维修系统时，磁盘队列长度偶尔会升至5。 几个月前，情况开始发生变化（所以不是在我们推出改变之后）。 磁盘队列警报开始涌入，平均队列长度在30秒。 我们让它运行几天，看看问题是否会消失（性能没有明显的影响，至less在目前的负载下）。 由于问题没有消失，我们认为可能是底层系统有问题，所以我们实例化了一个全新的Azure应用服务并迁移到那个。 同样的问题。 所以我们联系了Azure支持。 当然，他们要求我们运行一些无意义的testing，希望我们能够走开（他们要求networking追踪…对于磁盘队列问题！）。 我们不会轻易放弃，所以我们进行了无意义的testing，最终被告知只要将队列长度设置为50（超过10分钟）即可。 尽pipe我们无法控制底层硬件，基础架构和系统configuration，但这听起来不对。 他们的全部答复如下 我通过收集的信息与我们的产品团队联系。 他们调查了您为磁盘队列长度指定的警报发射频率超出预期的问题。 如果在5分钟内磁盘队列长度平均值超过10，则会将此警报设置为通知您。 此度量标准是采样间隔期间所选磁盘排队的读取和写入请求的平均数量。 对于Azure应用程序服务基础结构，以下文档链接讨论了此指标： https ： //docs.microsoft.com/en-us/azure/app-service-web/web-sites-monitor 对于部署的任何types的应用程序，值10非常低，因此您可能会看到误报。 这意味着警报可能比确切的连接数更频繁地触发。 例如，在每个虚拟机上，我们运行防恶意软件服务来保护Azure应用服务基础设施。 在这段时间内，您会看到已build立的连接，如果警报设置为较低的数字，则可以触发。 我们没有发现任何影响您网站可用性的反恶意软件扫描实例。 Microsoftbuild议您考虑在10分钟内将“磁盘队列长度”度量设置为至less50的平均值。 我们相信这个价值应该让你继续监视你的应用程序的性能目的。 它也应该受到我们为维护目的而运行的防恶意软件扫描或其他连接的影响。 任何人想要join？