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連接問題

我使用以下工具來幫助我解決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實例。）

 

經過Clustering For Mere Mortals的許可轉載。