インフラ – ページ 2 – はるかのブログ

Google Cloud Storageを公開する

ACLの確認

gsutil acl get gs://バケット名

レスポンス
[
  {
    "entity": "project-owners-xxxxxxxxxxx",
    "projectTeam": {
      "projectNumber": "xxxxxxxxxxx",
      "team": "owners"
    },
    "role": "OWNER"
  },
  {
    "entity": "project-editors-xxxxxxxxxxx",
    "projectTeam": {
      "projectNumber": "xxxxxxxxxxx",
      "team": "editors"
    },
    "role": "OWNER"
  },
  {
    "entity": "project-viewers-xxxxxxxxxxx",
    "projectTeam": {
      "projectNumber": "xxxxxxxxxxx",
      "team": "viewers"
    },
    "role": "READER"
  },
  {
    "entity": "allUsers",
    "role": "READ"
  }
]

全ユーザーにデータ書き込みを許可する

gsutil acl ch -u AllUsers:R gs://バケット名

レスポンス
Updated ACL on gs://バケット名/

全ユーザーにデータ読み込みを許可する

gsutil acl ch -u AllUsers:W gs://バケット名

レスポンス
Updated ACL on gs://バケット名/

wordpress をELB＋EC2でHTTPS通信させる

wordpressの移設に少し手間取ったのでメモ

wordpressやELB、EC2の動かし方は割愛するが、普通のやり方。

ただ、以前に借りていたVPSでLets EncryptでHTTPS化していたブログを移設した。

ハマった所1： wp-adminのリダイレクトループ
管理画面での SSL 通信

リンク先に書いているけど、wp-includes/default-constants.phpの、

[code]
if ( !defined( ‘FORCE_SSL_ADMIN’ ) ) {
if ( ‘https’ === parse_url( get_option( ‘siteurl’ ), PHP_URL_SCHEME ) ) {
define( ‘FORCE_SSL_ADMIN’, true );
} else {
define( ‘FORCE_SSL_ADMIN’, false );
}
}
[/code]

を

[code]
if ( !defined( ‘FORCE_SSL_ADMIN’ ) ) {
if ( ‘https’ === parse_url( get_option( ‘siteurl’ ), PHP_URL_SCHEME ) ) {
define( ‘FORCE_SSL_ADMIN’, true );
if ( ! empty( $_SERVER[‘HTTP_X_FORWARDED_PROTO’] ) && $_SERVER[‘HTTP_X_FORWARDED_PROTO’] == ‘https’ ) {
$_SERVER[‘HTTPS’]=’on’;
}
} else {
define( ‘FORCE_SSL_ADMIN’, false );
}
}
[/code]

に変更する。

ハマった所2： WPやプラグイン更新のFTP設定
config.phpの末尾に、

[code]
define(‘FS_METHOD’,’direct’);
[/code]

を記載する。

powershellでCPU情報を取得するアレコレ

[code]
# cpu情報を表示
Get-WmiObject -Class Win32_Processor

# 物理コア数を表示
Get-WmiObject -Class Win32_Processor | Format-List NumberOfCores

# 論理コア数を表示（THH）
Get-WmiObject -Class Win32_Processor | Format-List NumberOfLogicalProcessors
[/code]

と、色々と調べたけど、
[code]
Get-WmiObject -Class Win32_Processor | Format-List NumberOfCores, NumberOfLogicalProcessor
[/code]

が一番すっきりする

SQL Server から AWS Auroraにマイグレーションする時の注意事項

オンプレ環境のSQL Server開発機からAWS Auroraにマイグレーションした際、DMS（Database Migration Service）を使って見たので、ハマった処をメモ。
https://aws.amazon.com/jp/dms/

eyecatch_dms-200x200
※仕様をよく読んだら書いてあるのかもしれない。

【移設方法】
オンプレのSQLServerは、DMSからアクセスが出来ないネットワークにある為、セキュリティを弄らずに移設をする方法を考えました。
結果的に、[開発機] – [RDS for SQL Server] – [DMS] – [RDS for Aurora]
と余計なSQLServerを挟んでいます。

20161108_1

【移行時の注意点】
・DMSはスキーマ単位になりますが、Auroraはスキーマの概念がありません。
　SQLServerで
　[db_name1].[dbo].[table_name]
　[db_name2].[dbo].[table_name]
　は別テーブルとして扱われますが、Auroraでは[dbo].[table_name]と単一になります。

　その為、事前にスキーマを[ALTER SCHEMA db_name1 TRANSFER dbo.table_name]等のコマンドで変更しておく必要があります。
　対象は、一般テーブル、システムテーブルです

　また、ストアドもスキーマを変更する必要があります。
　こちらは変更のコマンドが解らなかったので、SSMSでストアドのCreate文作成　→　dboの部分をdb_nameに変更して新規作成を行いました。

・LOBサイズ
　DMSのLOBサイズの上限は、デフォルトで24KBになっています。
　大きめのデータが格納されている場合、この上限に引っかかる場合がありますので、適時変更を行ってください。
　分からなくても、1024KBぐらいあれば十分かと。

・移行元がSQLServerの場合、継続的なレプリケートが出来ない。
　DMSの強みである継続的レプリケート。
　これにより、大容量のデータベースでもダウンタイムを低減させる事が出来ます。
　が、現時点でSQLServerからAuroraへは、レプリケートが行いません。

・IDENTITIYはAutoIncrimentにならない
・datetimeoffset(7)　→　varchar(34)
この辺はエンジンの違いが出てきます。

追加のデータが入らないうちに、Alter Tableで変更しておきましょう。

パフォーマンスカウンタのネットワークのスケール

スケール調整の覚書

グラフ枠のプロパティ/グラフ/垂直スケール　の最大値を100から1000に上げる

NetworkInterface/NIC名/Bytes Sent/sec
　・・・　GigaNicを積んでいる場合、スケールは0.00001 でxxxMB/s
　　　　　※グラフ赤線

NetworkInterface/NIC名/Packet Sent/sec
　・・・　GigaNicを積んでいる場合、スケールは0.001　でxxxMbps
　　　　　※グラフ黄緑線

perfmon_20160913

RDS for SQL Serverのフルバック機能を検証する

先日、AWSのRDS for SQLServerのフルバックアップがS3のバケット上に置けるようになったので、触ってみる。
現時点ではトランザクションログバックアップが出来ないが、S3を使うことによりオンプレ環境から取得したフルバックアップのリストアや、解析用にフルバックアップを別サーバーにリストアするなど、
利用用途が増える。

参考：
Amazon RDS for SQL Server – Amazon S3 でネイティブバックアップと復元をサポート
 Importing and Exporting SQL Server Databases

事前準備：
リンク先に記載の通り、S3のバケット作成とIAMロールの作成を行う。
S3のバケット作成とIAMロールの作成は、RDSのオプショングループの作成画面からも行える。
ちなみに、default:sqlserver-xx グループには、オプションを追加することが出来ないので新規でオプショングループを準備する。

rds_s3_1

rds_s3_2

作成したオプショングループをインスタンスに割り当て、インスタンスの再起動を行うとRDS for SQLServerからS3へのアクセスが可能になる。

S3操作：
S3への操作は、AWSが準備したストアドプロシージャを実行する。

【フルバックアップ取得】
[sql]
exec msdb.dbo.rds_backup_database
@source_db_name=’DBスキーマ名’,
@s3_arn_to_backup_to=’arn:aws:s3:::S3バケット名/ファイル名.bk’,
@overwrite_S3_backup_file=1;
[/sql]

【DBリストア】
[sql]
exec msdb.dbo.rds_restore_database
@restore_db_name=’DBスキーマ名’,
@s3_arn_to_restore_from=’arn:aws:s3:::S3バケット名/ファイル名.bk’;
[/sql]

【タスク状態確認】
[sql]
exec msdb.dbo.rds_task_status @db_name=’DBスキーマ名’
[/sql]

RDS for SQLServerではメンテナンスプランが使えない為、以下のような処理をエージェントジョブで回すとフルバックアップ取得の代わりになる。
※保持期間を過ぎたバックアップファイルの削除を、lambdaなりAWSCLIなりで行う事。

[sql]
USE msdb

declare @Backet nvarchar(20)
declare @DATE nvarchar(10)
declare @DBNAME nvarchar(30)
declare @BackupFile nvarchar(50)

SET @Backet = ‘s3バケット名’
SET @DATE = (SELECT CONVERT(date, getdate()))

–データベース一覧を取得(master(ID=1),tempdb(ID=2),model(ID=3),msdb(ID=4) 以上)
DECLARE C1_DBNAME CURSOR FOR
SELECT NAME FROM SYS.DATABASES WHERE DATABASE_ID > ‘5’

OPEN C1_DBNAME

FETCH NEXT FROM C1_DBNAME INTO @DBNAME

WHILE (@@FETCH_STATUS = 0)

BEGIN

SET @BackupFile = N’arn:aws:s3:::’ + @Backet + ‘/’ + @DBNAME + ‘_’ + @DATE + ‘.bak’

IF @BackupFile IS NOT NULL
exec msdb.dbo.rds_backup_database
@source_db_name = @DBNAME,
@s3_arn_to_backup_to = @BackupFile,
@overwrite_S3_backup_file = 1;

FETCH NEXT FROM C1_DBNAME INTO @DBNAME
END

CLOSE C1_DBNAME
DEALLOCATE C1_DBNAME

GO
[/sql]

windows2012のQoSが効かない場合の注意点

新規にwindows2012サーバーを準備し、WindowsでポリシーベースのQOSを使ってS3へのアップロードスピードを帯域制御する方法をトレースしてみた。

QoSの設定はこの通りだが、「出力方向のスロットル率を指定する」には注意が必要。

検証では200MBbpsに設定を行ったが、物理1Gの回線環境で800MBps以上トラフィックが流れてしまう。
qos_1

qos_2

MSに問い合わせをして調査、検証を行った結果、

windows2012のインストール時点のQoSのバグっぽい事まで突き止める。
（Windowsアップデートしたら動きが改善されているので、どこかでパッチが当たった模様）

Windowsアップデート前：　制限の設定値の10倍が実際の制限値となる。
　・　QoSを200MBps（204800 KBps）に制限　→　トラフィックが200MBps以上
　・　QoSを 20MBps（20480 KBｐｓ）に制限　→　トラフィックは200MBps以下になる

Windowsアップデート後：　制限の設定値と同じ値が実際の制限値となる。
　・　QoSを200MBps（204800 KBps）に制限　→　トラフィックが200MBps以下になる

MSからKB番号の返答が来たら追記します。

コマンドラインからSQL Server2012をインストールする

覚書

以下のファイルを、ConfigurationFile.iniという名前で保存する。
[code]
;SQL Server 2012 Configuration File
[OPTIONS]

; INSTALL、UNINSTALL、UPGRADE などのセットアップワークフローを指定します。これは必須のパラメーターです。

ACTION="Install"
IACCEPTSQLSERVERLICENSETERMS="True"
; コマンドライン引数 ENU の詳細なヘルプが定義されていません。

ENU="False"

; ユーザーインターフェイスの動作を制御するパラメーターです。
; 有効な値は Normal (完全な UI の場合)、AutoAdvance (簡易 UI の場合)、および EnableUIOnServerCore (GUI ブロックをバイパスする Server Core セットアップの場合) です。

; UIMODE="NOMAL"

; ユーザーインターフェイスは表示されません。

QUIET="False"

; ユーザー操作はなく、進行状況だけが表示されます。

QUIETSIMPLE="True"

; SQL Server セットアップで更新プログラムを検出して含める必要があるかどうかを指定します。
; 有効な値は、True と False または 1 と 0 です。既定では、SQL Server セットアップには、検出された更新プログラムが含まれます。

UpdateEnabled="True"

; インストール、アンインストール、またはアップグレードを行う機能を指定します。
; 最上位の機能には、SQL、AS、RS、IS、MDS、ツールなどがあります。
; SQL 機能では、データベースエンジン、レプリケーション、フルテキスト、および Data Quality Services (DQS) サーバーがインストールされます。
; ツール機能では、管理ツール、オンラインブックコンポーネント、SQL Server Data Tools、その他の共有コンポーネントがインストールされます。

FEATURES=SQLENGINE,BIDS,CONN,BC,SDK,SSMS,ADV_SSMS,SNAC_SDK

; SQL Server セットアップが更新プログラムを取得する場所を指定します。
; 有効な値は、"MU" (Microsoft Update を検索)、有効なフォルダーパス、.\MyUpdates のような相対パス、または UNC 共有です。
; 既定では、SQL Server セットアップは Microsoft Update を検索するか、Window Server Update Services を通じて Windows Update サービスを検索します。

UpdateSource="MU"

; コマンドラインパラメーターの使用方法を表示します

HELP="False"

; 詳細なセットアップログをコンソールにパイプすることを指定します。

INDICATEPROGRESS="False"

; セットアップで WOW64 にインストールするよう指定します。このコマンドライン引数は、IA64 や 32 ビットシステム上ではサポートされません。

X86="False"

; 共有コンポーネントのルートインストールディレクトリを指定します。このディレクトリは、共有コンポーネントのインストール後は変更されません。

INSTALLSHAREDDIR="C:\Program Files\Microsoft SQL Server"

; WOW64 共有コンポーネントのルートインストールディレクトリを指定します。このディレクトリは、WOW64 共有コンポーネントのインストール後は変更されません。

INSTALLSHAREDWOWDIR="C:\Program Files (x86)\Microsoft SQL Server"

; 既定のインスタンスまたは名前付きインスタンスを指定します。既定のインスタンスは、Express 以外のエディションの場合は MSSQLSERVER、Express エディションの場合は SQLExpress です。SQL Server データベースエンジン (SQL)、Analysis Services (AS)、または Reporting Services (RS) のインストール時には、このパラメーターが必須です。

INSTANCENAME="MSSQLSERVER"

; 指定した SQL Server 機能のインスタンス ID を指定してください。SQL Server のディレクトリ構造、レジストリ構造、およびサービス名には、SQL Server インスタンスのインスタンス ID が組み込まれます。

INSTANCEID="MSSQLSERVER"

; SQL Server 機能の使用状況データを収集して Microsoft へ送信できるようにするかどうかを指定します。この機能を有効にするには 1 または True を指定し、無効にするには 0 または False を指定します。

SQMREPORTING="False"

; 今後のリリースの SQL Server の改善のため、Microsoft にエラーを報告できるようにするかどうかを指定します。この機能を有効にするには 1 または True を指定し、無効にするには 0 または False を指定します。

ERRORREPORTING="False"

; インストールディレクトリを指定します。

INSTANCEDIR="C:\Program Files\Microsoft SQL Server"

; エージェントアカウント名

AGTSVCACCOUNT="gree-rogue\Administrator"
AGTSVCPASSWORD="パスワード"
; インストール後にサービスを自動的に開始します。

AGTSVCSTARTUPTYPE="Automatic"

; CM ブリックの TCP 通信ポート

COMMFABRICPORT="0"

; マトリックスでのプライベートネットワークの使用方法

COMMFABRICNETWORKLEVEL="0"

; ブリック間の通信を保護する方法

COMMFABRICENCRYPTION="0"

; CM ブリックで使用される TCP ポート

MATRIXCMBRICKCOMMPORT="0"

; SQL Server サービスのスタートアップの種類。

SQLSVCSTARTUPTYPE="Automatic"

; FILESTREAM 機能を有効にするレベル (0、1、2、または 3)。

FILESTREAMLEVEL="0"

; SQL Server Express で RANU を有効にするには、"1" に設定します。

ENABLERANU="False"

; データベースエンジンに使用する Windows 照合順序または SQL 照合順序を指定します。

SQLCOLLATION="Japanese_CI_AS"

; SQL Server サービスのアカウント: ドメイン\ユーザーまたはシステムアカウント。

SQLSVCACCOUNT="administrator"
SQLSVCPASSWORD="パスワード"

; SQL Server のシステム管理者として準備する Windows アカウント。

SQLSYSADMINACCOUNTS="administrator"

; 既定値は Windows 認証です。混合モード認証の場合は "SQL" を使用してください。

SECURITYMODE="SQL"

; データベースエンジンのバックアップファイルの既定のディレクトリ。

SQLBACKUPDIR="C:\database\backup"

; データベースエンジンのユーザーデータベースの既定のディレクトリ。

SQLUSERDBDIR="F:\database\db"

; データベースエンジンのユーザーデータベースログの既定のディレクトリ。

SQLUSERDBLOGDIR="C:\database\log"

; データベースエンジンの TempDB ファイルのディレクトリ。

SQLTEMPDBDIR="F:\database\db"

; データベースエンジンの TempDB ログファイルのディレクトリ。

SQLTEMPDBLOGDIR="F:\database\tmp"

; 現在のユーザーを SQL Server 2012 Express のデータベースエンジンシステム管理者として準備します。

ADDCURRENTUSERASSQLADMIN="False"

; TCP/IP プロトコルを無効にするには 0 を、有効にするには 1 を指定します。

TCPENABLED="1"

; Named Pipes プロトコルを無効にするには 0 を、有効にするには 1 を指定します。

NPENABLED="0"

; Browser サービスのスタートアップの種類。

BROWSERSVCSTARTUPTYPE="Disabled"

[/code]

コマンドプロンプトを開き、
[code]
インストールメディア内setup.exe /SAPWD="SQL認証時のsaのパスワード" /ConfigurationFile="保存したConfigurationFile.ini"
[/code]

Elastic CacheにAWS外からアクセスする

基本的にはAWS 外部からの ElastiCache リソースへのアクセスの通り。

Elastic CacheにはAWS以外からのアクセスが出来ないので、
インターネット-[Elastic IP]–[EC2]–[Elastic Cache]
みたいに、中間にEC2インスタンスを噛ます必要がある。

EC2は、PREROUTINGしかt1.microインスタンスでも十分じゃないかな

[code]
#中間のEC2上で

iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 6379 -j DNAT –to ElasticCacheのIP:6379
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables-save

#/etc/sysctl.conf
net.ipv4.ip_forward = 1

sysctl -a
[/code]