SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

将Internet Explorer 11从Bing更改为Google

by Leave a Comment

在Internet Explorer 11中将默认搜索提供程序从Bing更改为Google＃IE11 #GOOGLE #BING

在Internet Explorer 11中将默认搜索提供程序从Bing更改为Google＃IE11 #GOOGLE #BING

对于那些仍然不时使用IE 11的人，您可能已经注意到，在最近的更新中，您的默认搜索提供程序可能已更改为Bing。如果您想了解如何将Internet Explorer 11从Bing更改为Google，请继续阅读。微软已经进行了安全性增强。它希望通过更改默认搜索引擎和主页来阻止恶意软件劫持浏览器。我是两个十几岁的“游戏玩家”的父亲，他们总是处于下载最新恶意软件的边缘。因此，虽然我很欣赏增加的安全性，但仍有一点点担心。此安全更新的一个“好处”是默认搜索提供程序现在是Bing。将其切换回Google并不像1-2-3那么容易。Microsoft在其文章中发布了有关如何将Bing Explorer 11从Bing更改为Google的步骤：http：//windows.microsoft.com/en-us/windows-10/internet-explorer-11-settings-protection不要请记住我  我喜欢微软的产品。但不幸的是，Bing对我所做的搜索类型并不友好，因为它通常会寻找一些非常具体的技术内容。我认为Bing可能对消费者友好。然而，谷歌在给我答案的过程中赢得了搜索引擎大战

将Internet Explorer 11从Bing更改为Google

要将Internet Explorer 11从Bing更改为Google，请按照本文中的这些步骤操作。下面的屏幕截图显示了步骤。将Internet Explorer 11从Bing更改为Google 将Internet Explorer 11从Bing更改为Google 将Internet Explorer 11从Bing更改为Google 将Internet Explorer 11从Bing更改为Google

Azure门户GUI上的不同名称

by Leave a Comment

Azure门户GUI上的不同名称

“Badrequest：虚拟网络Public-Azure-East不存在”门户网站中显示的虚拟网络名称可能是错误的#Azure #Azureclassic

今天，我学到了一些新东西 – Azure门户GUI上的不同名称。我试图帮助客户在Azure Classic中部署一些具有两个NIC卡的VM。没问题我说，自从我使用Azure Classic以来已经有一段时间了。 我记得这很简单，虽然它必须通过PowerShell完成，因为门户网站中没有用于部署两个NIC的GUI选项。基本方向可以在这里找到。https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-multiple-nics/然而，在我的头撞墙几个小时之后，我偶然发现了这个信息。https://thelonedba.wordpress.com/2015/07/17/new-azurevm-badrequest-the-virtual-network-foo-does-not-exist

Azure门户GUI上的不同名称

看起来Azure门户GUI关于虚拟网络名称的说法有时可能与运行Get-AzureVMNetSite时返回的实际名称完全不同。选择名称。从本质上讲，Azure门户GUI上有一个不同的名称。为什么会这样呢？请参阅下面的屏幕截图。我创建的名为“Public-Azure-East”的虚拟网络实际上称为“Group Group Azure Public East”。如何发生这种情况以及为什么Azure门户GUI上有不同的名称是我无法理解的。如您所见，我在创建虚拟机时的微弱尝试失败了。它说“BadRequest：虚拟网络Public-Azure-East不存在。”我确信它与我使用的多个订阅有关。但事实证明，这是一个在Azure门户GUI上显示不同名称的错误。Azure门户GUI上的不同名称 Azure门户GUI上的不同名称 为什么像创建具有两个NIC的VM这样简单的事情无法通过GUI实现完全是另一个故事。经Clusteringformeremortals.com许可转载

SQL Server标准版的灾难恢复

by Leave a Comment

SQL Server Standard Edition的灾难恢复

将双节点SQL Server 2012/2014标准版群集复制到第三台服务器以进行灾难恢复

使用SIOS DataKeeper Cluster Edition可以对SQL Server Standard Edition进行灾难恢复。就是这样。由于SQL Server Enterprise Edition的成本，许多人发现自己已经开始使用SQL Server Standard Edition。SQL Server标准版具有许多相同的功能，但它有一些限制。一个限制是它不支持AlwaysOn可用性组。此外，它仅支持群集中的两个节点。由于数据库镜像已被弃用且仅支持标准版中的同步复制，因此您实际上具有有限的灾难恢复选项。

SQL Server Standard Edition的灾难恢复

其中一个选项是SIOS DataKeeper Cluster Edition。DataKeeper将与您现有的共享存储群集配合使用。该软件允许您使用同步或异步复制将其扩展到第3个节点。如果您使用的是SQL Server Enterprise，只需将该第3个节点添加为真正的多站点群集的另一个群集成员即可。但是，由于我们讨论的是SQL Server Standard Edition，因此无法将第3个节点直接添加到群集中。好消息是DataKeeper将允许您将数据复制到第三个节点，以便您的数据受到保护。SQL Server Standard Edition的灾难恢复意味着您将使用DataKeeper将第3个节点作为镜像源联机。接下来，使用SQL Server Management Studio装载复制卷上的数据库。您的客户还需要重定向到第3个节点。但它是一种非常具有成本效益的解决方案，具有出色的RPO和合理的RTO。SIOS文档讨论了如何为SQL Server Standard Edition执行灾难恢复。在这里，我总结了一些客户最近的步骤。

组态

  • 停止SQL资源
  • 从SQL群集资源中删除物理磁盘资源
  • 从可用存储中删除物理磁盘
  • SECONDARY服务器上的在线物理磁盘。添加驱动器号（如果没有）
  • 运行emcmd。setconfiguration <驱动器号> 256并重新引导辅助服务器。这将导致SECONDARY服务器阻止访问E驱动程序。这是一个重要的步骤，因为您不希望两台服务器同时访问E驱动器，如果您可以避免它。
  • 在PRIMARY服务器上联机磁盘
  • 如果需要，添加驱动器号
  • 创建从主服务器到DR的DataKeeper镜像您可能需要等待一分钟才能在所有服务器上的DataKeeper服务器概述报告中显示E驱动器，然后才能正确创建镜像。如果操作正确，您将创建一个从PRIMARY到DR的镜像。 作为该过程的一部分，DataKeeper将询问您共享您正在复制的卷的SECONDARY服务器。

在灾难中……

在DR NODE上

  • 运行EMCMD。switchovervolume <驱动器号>
  • 第一次确保SQL Service帐户具有对所有数据和日志文件的读/写访问权限。您第一次尝试装入数据库时​​必须明确授予此访问权限。
  • 使用SQL Management Studio装入数据库
  • 将所有客户端重定向到DR站点中的服务器。更好的是，预先配置驻留在DR站点中的应用程序指向DR站点中的SQL Server实例。

灾难结束后

  • 重新启动主站点中的服务器（PRIMAY，SECONDARY）
  • 等待镜像达到镜像状态
  • 确定哪个节点是以前的源（以管理员身份运行PowerShell）get-clusterresource -Name“<DataKeeper Volume Resource name>”|得到-clusterparameter
  • 确保群集中没有DataKeeper卷资源在线
  • 在一个群集节点上启动DataKeeper GUI。解决任何裂脑情况（很可能没有），确保在任何裂脑恢复过程中选择DR节点作为源
  • 在报告为上一个源的节点上运行EMCMD。switchovervolume <驱动器号>
  • 在故障转移群集管理器中使SQL Server联机

上述步骤假设您在所有三台服务器（PRIMARY，SECONDARY，DR）上安装了SIOS DataKeeper Cluster Edition。PRIMARY和SECONDARY是一个双节点共享存储集群。您正在将数据复制到DR，这只是一个独立的SQL Server实例（不是群集的一部分），只有本地附加存储。灾难恢复服务器将具有与共享群集卷大小和驱动器号相同的卷。这项工作相当不错，如果您没有配置自己的灾难恢复站点，甚至可以让您复制到云中的目标。如果要完全消除SAN，还可以使用所有复制存储构建相同的配置。这是一个很好的短视频，演示了SQL Server Standard Edition的灾难恢复的一些可能配置。 http://videos.us.sios.com/medias/aula05u2fl经Clusteringformeremortals.com许可转载

使用Azure资源管理器支持的服务（ARM）

by Leave a Comment

Azure服务管理（经典）或Azure资源管理器（ARM）？

我每周都会与用户进行交流，将关键业务工作负载转移到Azure。我经常问的第一个问题是他们是使用Azure服务管理（经典）还是Azure资源管理器（ARM）。

我通常推荐ARM。 这是一种新的做事方式，所有新功能都在为ARM开发。不过，还有一些与ARM不兼容的东西。随着时间的推移，这些不支持的功能列表越来越小。同时，最好知道现有的文档似乎定期更新，列出了所有功能以及它们是否受ARM支持。 https://azure.microsoft.com/en-us/documentation/articles/resource-manager-supported-services/

这是一个体面的名单，但它不完整。我只在应用程序服务环境页面的此页面上发现应用程序服务环境不受支持。

修复SQL Server Alwayson故障转移群集实例中的Azure ILB连接

by Leave a Comment

在SQL Server故障转移实例群集连接中排查Azure ILB连接问题

我使用以下工具来帮助我解决SQL Server故障转移群集实例连接问题的疑难解答。特别是那些讨厌的Azure ILB连接问题。每当我找到一个新工具时，我都会尝试更新这篇文章。

NETSTAT

第一个工具是一个简单的测试，用于验证SQL群集IP是否正在侦听它应该侦听的端口。在这种情况下，SQL群集IP地址是10.0.0.201。但它使用的是端口1433的默认实例。这里是帮助你快速识别活动节点是否在该端口上侦听的命令。在我们的情况下，一切看起来很正常

C： Users  dave.SIOS> netstat -na |找到“1433”
TCP 10.0.0.4:49584 10.0.0.201:1433 ESTABLISHED
TCP 10.0.0.4:49592 10.0.0.201:1433 ESTABLISHED
TCP 10.0.0.4:49593 10.0.0.201:1433 ESTABLISHED
TCP 10.0.0.4:49595 10.0.0.201:1433 ESTABLISHED
TCP 10.0.0.201:1433 0.0.0.0:0听
ESTABLISHED
TCP 10.0.0.201:1433 10.0.0.4:49592 ESTABLISHED
TCP 10.0.0.201:1433 10.0.0.4:49593 ESTABLISHED
TCP 10.0.0.201:1433 10.0.0.4:49595 ESTABLISHED

一旦我确定SQL正在监听正确的端口，我使用PSPING尝试远程连接到端口。

PSPING

PSPing是Microsoft提供的PSTools软件包的一部分。我通常下载该工具并将PSPing直接放在我的System32文件夹中，这样我就可以随时使用它而无需更改目录。现在，假设从ILB，集群和防火墙的角度来看，所有配置都是正确的，那么您应该能够从被动服务器ping SQL集群IP地址和端口1433。你会得到下面显示的结果…

C： Users  dave.SIOS> psping 10.0.0.201:1433
PsPing v2.01  -  PsPing  -  ping，延迟，带宽测量工具
Copyright（C）2012-2014 Mark Russinovich
Sysinternals  -  www.sysinternals.com
TCP连接到10.0.0.201:1433：
5次迭代（热身1）连接测试：
连接到10.0.0.201:1433（热身）：6.99ms
连接到10.0.0.201:1433：0.78ms
连接到10.0.0.201:1433：0.96ms
连接到10.0.0.201:1433：0.68ms
连接到10.0.0.201:1433：0.89ms
如果事情没有正确配置，您可能会看到与以下类似的结果...
C： Users  dave.SIOS> psping 10.0.0.201:1433
TCP连接到10.0.0.102:1433：
5次迭代（热身1）连接测试：
连接到10.0.0.102:1433（热身）：由于超时期限过期，此操作返回。连接到10.0.0.102:1433（热身）：由于超时期限过期，此操作返回。连接到10.0.0.102:1433（热身）：由于超时期限过期，此操作返回。连接到10.0.0.102:1433（热身）：由于超时期限过期，此操作返回。连接到10.0.0.102:1433（热身）：由于超时期限过期，此操作返回。

如果PSPing连接，但您的应用程序连接出现问题，则可能需要深入一点。我见过像Great Plains这样的应用程序也想连接到445端口。如果您的应用程序无法连接，但PSPing可以很好地连接到1433。然后，您可能需要执行网络跟踪并查看应用程序尝试连接的其他端口。最后一步是为这些端口添加负载平衡规则。

命名实例

计划使用命名实例？您需要确保锁定TCP服务以使用静态端口。同时，您还需要确保向负载平衡器添加规则，以重定向SQL浏览器服务的UDP 1434。否则，您将无法连接到您的命名实例。

FIREWALL

打开TCP端口1433和59999应该涵盖所有需要的手动步骤。但是，在解决连接问题时，我通常关闭Windows防火墙以消除防火墙，将其视为问题的可能原因。别忘了。Azure还有一个称为网络安全组的防火墙。如果有人将其从可能阻止流量的默认设置改变。

姓名解析

尝试ping SQL集群名称。它应该解析为SQL Server群集iP地址。尽管我已经看到过几次，但与SQL群集网络名称关联的DNS A记录神奇地从DNS中消失。如果是这种情况，请继续阅读 – 在SQL中将SQL Custer名称和IP地址作为A记录进行读取。

SQL配置管理器

在SQL配置管理器中，您应该看到列出的SQL群集IP地址和端口1433。如果碰巧你安装了一个命名实例，你当然需要进入这里并将端口锁定到一个特定的端口，并使你的负载平衡规则反映该端口。由于Azure ILB仅限于每个AG的ILB限制，所以实际上我没有看到使用命名实例的有效理由。让自己更容易，只使用SQL的默认实例。（更新：截至2016年10月，每个ILB可以有多个IP地址，因此您可以在群集中安装多个SQL实例。）

 

转载自群集成为凡人的许可。