「クラウド」カテゴリーアーカイブ

令和になったことだしクラウドへ移行する – 14 – KUSANAGIのバージョンアップとfunctions.sh(2)

ども。こんばんは。

以前も記事にしたサブディレクトリでkusanagiを動かす場合に修正が必要な/usr/lib/kusanagi/lib/functions.shですが、kusanagi-8.4.3-3くらいからいじる箇所が増えたみたいです。

これをしないと一部kusanagiコマンドが「WordPress がインストールされていません。何もしません」という表示になります。

以下、8.4.4-2対応版です。

168,169c168,169
< elif [ -e $TARGET_DIR/DocumentRoot/wp-config.php ]; then
< WPCONFIG=”$TARGET_DIR/DocumentRoot/wp-config.php”

> elif [ -e $TARGET_DIR/DocumentRoot/blog/wp-config.php ]; then
> WPCONFIG=”$TARGET_DIR/DocumentRoot/blog/wp-config.php”
1718c1718
< [ -e $KUSANAGI_DIR/DocumentRoot/wp-config.php ] || [ -e $KUSANAGI_DIR/wp-config.php ] || return

> [ -e $KUSANAGI_DIR/DocumentRoot/blog/wp-config.php ] || [ -e $KUSANAGI_DIR/wp-config.php ] || return
1785,1786c1785,1786
< if [ -e $KUSANAGI_DIR/DocumentRoot/wp-content/mu-plugins/wp-kusanagi.php ] && \
< [ -e $KUSANAGI_DIR/DocumentRoot/wp-content/mu-plugins/kusanagi-wp-configure.php ]; then

> if [ -e $KUSANAGI_DIR/DocumentRoot/blog/wp-content/mu-plugins/wp-kusanagi.php ] && \
> [ -e $KUSANAGI_DIR/DocumentRoot/blog/wp-content/mu-plugins/kusanagi-wp-configure.php ]; then
1788c1788
< local MU_PLUGINS_DIR=”$KUSANAGI_DIR/DocumentRoot/wp-content/mu-plugins”

> local MU_PLUGINS_DIR=”$KUSANAGI_DIR/DocumentRoot/blog/wp-content/mu-plugins”

動作okっぽいですが、修正は自己責任でお願いします。

# kusanagi bcache
bcache は有効です
完了しました。

# kusanagi update plugin
KUSANAGI プラグインは、既に最新バージョンです。
KUSANAGI 設定プラグインは、すでに最新バージョンです。
完了しました。

【バックナンバー】

ではでは。またの機会に。

令和になったことだしクラウドへ移行する – 13 – KUSANAGIのバージョンアップとfunctions.sh

—-
2019/11/02追記
8.4.3-3 あたりから修正箇所が増えているようです。

令和になったことだしクラウドへ移行する – 14 – KUSANAGIのバージョンアップとfunctions.sh(2)
—-

ども。こんばんは。

このブログはkusanagiで動いています。

8.4.3-1が出ていたので更新しました。

で、見ての通りサブディレクトリにkusanagiをインストールしています。

なので、kusanagiのバージョンアップとかをしたときにちょっとした設定の書き換えをしないとこうなります。

# kusanagi update plugin
プラグインファイルが存在ません。何もしません。
完了しました。

# kusanagi bcache
WordPress がインストールされていません。何もしません
完了しました。

という感じになります。

で、以下のファイルを修正。

/usr/lib/kusanagi/lib/functions.sh

# diff functions.sh.bak.20190728 functions.sh
166,167c166,167
< elif [ -e $TARGET_DIR/DocumentRoot/wp-config.php ]; then
< WPCONFIG=”$TARGET_DIR/DocumentRoot/wp-config.php”

> elif [ -e $TARGET_DIR/DocumentRoot/blog/wp-config.php ]; then
> WPCONFIG=”$TARGET_DIR/DocumentRoot/blog/wp-config.php”
1761,1762c1761,1762
< if [ -e $KUSANAGI_DIR/DocumentRoot/wp-content/mu-plugins/wp-kusanagi.php ] && \
< [ -e $KUSANAGI_DIR/DocumentRoot/wp-content/mu-plugins/kusanagi-wp-configure.php ]; then

> if [ -e $KUSANAGI_DIR/DocumentRoot/blog/wp-content/mu-plugins/wp-kusanagi.php ] && \
> [ -e $KUSANAGI_DIR/DocumentRoot/blog/wp-content/mu-plugins/kusanagi-wp-configure.php ]; then
1764c1764
< local MU_PLUGINS_DIR=”$KUSANAGI_DIR/DocumentRoot/wp-content/mu-plugins”

> local MU_PLUGINS_DIR=”$KUSANAGI_DIR/DocumentRoot/blog/wp-content/mu-plugins”

これで動くようになります。

【バックナンバー】

ではでは。またの機会に。

令和になったことだしクラウドへ移行する – 12 – AWSの初障害を味わう

ども。こんばんは。

当ブログですが、2019/06/25 11:00(JST)頃からアクセス不可になっていたようです。

というのも、このブログはAWS上で稼働していますが、運悪くインスタンスが乗っかっているハードウェアで障害が起きてしまったようです。

気づくのにだいぶ遅れましたが、以下のようなメールが届いていました。

Amazon EC2 Instance Retirement [AWS Account ID: xxxx]

Hello,

EC2 has detected degradation of the underlying hardware hosting your Amazon EC2 instance (instance-ID: i-xxxx) associated with your AWS account (AWS Account ID: xxx) in the us-east-1 region. Due to this degradation your instance could already be unreachable. We will stop your instance after 2019-07-09 02:00 UTC.

You can find more information about maintenance events scheduled for your EC2 instances in the AWS Management Console (https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#Events)

(以下略)

まとめると、あんたのインスタンスが乗ってるハードウェアがぶっ壊れてもうすでに接続できないよ、7/9に吹き飛ばすよ、ということらしいです。

参考:AWSのインスタンスリタイアお知らせが来た時の対処

メールは家に帰ってから見たのですが、コンソール上でも以下のようなメッセージが確認できました。

というか、EC2のところで、ステータスチェックでずっとエラーになってました。(←キャプチャは取り忘れ)

でまぁ、再起動(stop->start)したら直りました。

なかなか止まらなくて、stopを何度かしてようやく止まった感じです。

ちなみに焦ってTerminate(終了)しそうになりましたが、どうやらAWSのTerminateはインスタンスをふっとばす機能みたいですね。。。恐ろしい。

どれほど効果があるか調べてないですが、削除の保護を設定しておきました。

うーん、こういう障害は初めてですね。こうならないようにアヴェイラヴィリティゾーンとかを設定しなきゃですが、まぁ個人だしそこは仕方ない。。。

一瞬、今後ののためにIncapsulaでServe Stale Contentを効かせて、インスタンス障害時もコンテツキャッシュから返すようにしようかと悩みましたが、うーん、まぁやめとこう。それよりもステータスチェックに失敗したら携帯にメールを飛ばそう。。。

ということでこんな感じに設定してみました。

自動で再起動もできるようですが、ちょっとそれも不安なので一旦通知のみです。

間隔としきい値は適当です。CloudWatchのことまだ良くわかってない・・・。
できれば、こんな感じにCPUクレジットが0になっても通知するの作りたいと思いつつまだできてません。

ちなみにトピック名とやらは日本語不可です。エラーになりました。

で、ここに入力したメールアドレスが初めて登録したものの場合、認証メールが来るみたいです。

認証したところ。

実際に動かしてみないとわからないことが多いですね。

【バックナンバー】

ではでは。またの機会に。

令和になったことだしクラウドへ移行する – 11 – AWSからはじめての請求がきた

ども。こんばんは。

2019/6/3に請求が来ていました。

$1.29でした。

t2.microは無料なので、データ転送量だけ課金された感じです。

以下にプラスして消費税$0.1で、$1.29でした。

 

Data Transfer

$1.19

US East (N. Virginia)

AWS Data Transfer USE1-APN1-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from Asia Pacific (Tokyo)
0.005 GB
$0.00
AWS Data Transfer USE1-APN1-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to Asia Pacific (Tokyo)
0.116 GB
$0.00
AWS Data Transfer USE1-APS1-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from Asia Pacific (Singapore)
0.000000070 GB
$0.00
AWS Data Transfer USE1-APS1-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to Asia Pacific (Singapore)
0.000000040 GB
$0.00
AWS Data Transfer USE1-CAN1-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from Canada (Central)
0.000000070 GB
$0.00
AWS Data Transfer USE1-CAN1-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to Canada (Central)
0.000000040 GB
$0.00
AWS Data Transfer USE1-CloudFront-In-Bytes
$0.00

$0.00 per GB data transfer in to US East (Northern Virginia) from CloudFront
0.000011 GB
$0.00
AWS Data Transfer USE1-CloudFront-Out-Bytes
$0.00

$0.00 per GB data transfer out of US East (Northern Virginia) to CloudFront
0.000003 GB
$0.00
AWS Data Transfer USE1-EUC1-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from EU (Germany)
0.000002 GB
$0.00
AWS Data Transfer USE1-EUC1-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to EU (Germany)
0.000093 GB
$0.00
AWS Data Transfer USE1-EUN1-AWS-In-Bytes
$0.00

USD 0.0 per GB for EUN1-AWS-In-Bytes in EU (Stockholm)
0.000000430 GB
$0.00
AWS Data Transfer USE1-EUN1-AWS-Out-Bytes
$0.00

USD 0.02 per GB for EUN1-AWS-Out-Bytes in EU (Stockholm)
0.000001 GB
$0.00
AWS Data Transfer USE1-EUW2-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from EU (London)
0.000000070 GB
$0.00
AWS Data Transfer USE1-EUW2-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to EU (London)
0.000000040 GB
$0.00
AWS Data Transfer USE1-USW1-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from US West (Northern California)
0.000004 GB
$0.00
AWS Data Transfer USE1-USW1-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to US West (Northern California)
0.000010 GB
$0.00
AWS Data Transfer USE1-USW2-AWS-In-Bytes
$0.00

$0.00 per GB – US East (Northern Virginia) data transfer from US West (Oregon)
0.000157 GB
$0.00
AWS Data Transfer USE1-USW2-AWS-Out-Bytes
$0.00

$0.02 per GB – US East (Northern Virginia) data transfer to US West (Oregon)
0.012 GB
$0.00
Bandwidth
$1.19

$0.000 per GB – data transfer in per month
6.862 GB
$0.00
$0.000 per GB – data transfer out under the monthly global free tier
15 GB
$0.00
$0.000 per GB – regional data transfer under the monthly global free tier
0.035 GB
$0.00
$0.090 per GB – first 10 TB / month data transfer out beyond the global free tier
13.214 GB
$1.19

結局アウトバウンドトラフィックだけ課金ってことなかな。

IncapsulaでCDN効かせてるのでそこそこ節約してる・・・と信じたい。

 

Bandwidth
$1.19

$0.000 per GB – data transfer in per month
6.862 GB
$0.00
$0.000 per GB – data transfer out under the monthly global free tier
15 GB
$0.00
$0.000 per GB – regional data transfer under the monthly global free tier
0.035 GB
$0.00
$0.090 per GB – first 10 TB / month data transfer out beyond the global free tier
13.214 GB
$1.19

【バックナンバー】

ではでは。またの機会に。

令和になったことだしクラウドへ移行する – 10 – CloudFlare+Incapsulaの多段化はやっぱり無理

ども。こんばんは。

今日は連投ですね。

令和になったことだしクラウドへ移行する – 9 – t2.micro激重の原因とKUSANAGIのキャッシュの本気、CloudFlare+Incapsulaの多段化

にごちゃごちゃ追記したのですが、結論やっぱり無理です。

しばらくすると、IncapsulaでError Code 23になってしまいました。

その後、CloudFlareのCDNをoff(=DNS上、www.hits-net.comの解決結果がIncapsulaのCNAME)状態であれば通ります。

これを何度か再現テストして今の所再現率100%なので、やはり、IncapsulaのProxyは名前解決をちゃんと見ているのかもしれませんし、Free Planゆえのなにかかもしれません。

一応Error code 23の主要な原因はこれです。

https://support.incapsula.com/hc/en-us/articles/231496108-Grace-period-for-removed-sites
※24時間以内に同じFQDNを追加削除すると駄目だよっていう感じの話。

以下、完全に推測です。もしかしたら本当にIncapsulaがゴミ持ってるかもしれないし・・・。

上述の動作なら通常テストするときにhostsファイルに書いてアクセスしても同じことが起きるんじゃ?と思いますが・・・。

おそらくですが、hostsを編集した状態でアクセスしても、

元々のDNS(=Incapsulaが知っているDNS解決結果)と同じなら、通してくれる
※都度かどうかはわからないがIncapsula自身が名前解決をしている。これはoriginに対してではなく保護対象として登録したFQDNに対してと思われる。(OriginがCNAMEの場合はもちろん名前解決しますが、今回はOriginはIPアドレス直接指定なので)

のではないかと思います。

CloudFlareを前段に持ってきてCDNをOnにすると、IPアドレスの解決結果はあくまでCloudFlareです。

ということは、Incapsullaからすると、www.hits-net.comは、元々Incapsulaが最初にスキャンしたOriginのIPでもなく、Incapsulaが払い出したCNAMEでもない第3の「なにか(=ここではCloudFlare)」を解決してしまうことになります。
確かにこのパターンはそうそうないかも。

多分それが今回のError Code 23の原因かと。しばらくうまく行ったように感じるのは、CloudFlareのキャッシュが帰ってくるからかと思います。

CloudFlareのCDNをoffにすると割とすぐにError code 23はなくなります。(CloudFlareのTTLが300秒なので多分最大5分待てばいい。)

これCNAME Reuse使えれば話は違うんだろうけどなぁ。
OriginをCNAMEで登録したいなぁ。

もういいや、ということで、多段は諦めて、Incapsulaでキャッシュすることにしました。

【バックナンバー】

ではでは。またの機会に。

令和になったことだしクラウドへ移行する – 9 – t2.micro激重の原因とKUSANAGIのキャッシュの本気、CloudFlare+Incapsulaの多段化

ども、こんにちは。

前回の記事でt2.microのCPUクレジットを使い切って激重になった話を書かせていただきました。

んで、まぁ適当にKUSANAGIのnginxのログを解析していると・・・・

[root@kusanagi80 nginx]# zcat access.log-20190508 | awk ‘{ print $NF,$2,$3,$12,$10,$15,$16 }’ | sort | uniq -c | sort -rn | head -n 10
18840 “138.68.229.65” – – 200 /blog//xmlrpc.php “Mozilla/5.0 (Windows
(1位以下はすでに桁が全く違うので割愛)

どうもbot臭いのです。

「xmlrpc.php」へのアクセスを時間帯別に解析してみると、まぁ激重時間と大体一緒ですかね。

また、CdloufFlareがキャッシュしていなかったのも納得です。

[root@kusanagi80 nginx]# zcat access.log-20190508.gz |grep /blog//xmlrpc.php | awk ‘{ print $7 }’ | cut -b 2-15 | sort | uniq -c | sort -rn | head -n 10
4345 07/May/2019:17
4317 07/May/2019:16
4021 07/May/2019:18
3707 07/May/2019:15
541 07/May/2019:20
538 07/May/2019:19
519 07/May/2019:21
508 07/May/2019:22
345 07/May/2019:23
7 07/May/2019:12

ということで、CloudFlareで bot対策をしようと思ったのですが、無償だとGoogleなどのbotも止めてしまいそうです。

Before getting started

Cloudflare Firewall Rules can affect how traffic from known bots is handled. For details, see this FAQ.

ふむ。よろしい。ならばここに関しては無償のIncapsulaのほうが向いてるな。ということで、いつか失敗した多段に再挑戦します。

が、その前に、ちょっとKUSANAGIのbcacheとfcacheを設定してみます。

参考:詳解!KUSANAGIキャッシュ講座

で、うちの場合は、サブディレクトリにWordPressをおいていますので、まずはKUSANAGIのシェルを修正します。

まぁこの辺みながら雰囲気で。fcacheは早い話、nginxのリバースプロキシ機能でのキャッシュ、bcacheは動的に生成されるページを一定期間HTMLとして静的に保存する。両方組み合わせれば、bcacheで静的に生成されたHTMLをリバプロがキャッシュして返してくれると。

参考:KUSANAGIでサブディレクトリにWordPressを複数インストールする

で、onにします。

さて、実際効果はあるのかというところをちょっとテストしてみます。

WebPageTestで測ってみました。
※Tokyo, Japan – EC2 – Chromeで。

  • 旧オンプレサイト(CentOS Cpu 4コア/Mem:3GB)
    • https://www.webpagetest.org/result/190508_47_351c4d9104d0ca884007a289d9065993/
    • First Bytes 1.958s Fully Load 20.796s
  • 新サイト(AWS t2.micro) CloudFlareなし
    • https://www.webpagetest.org/result/190508_T5_c5f0471c39b6ab87f8c1434dd7518f10/
    • First Bytes 2.817s Fully Load 20.163s
    • 流石にCPU性能、メモリ性能では旧オンプレ環境に負けてるので遅いですね。
  • 新サイト(AWS t2.micro) + CloudFlare
    • https://www.webpagetest.org/result/190508_AR_24e95db4462d767499f2b0859ef05bed/
    • First Bytes 2.065s Fully Load 17.114s
    • お、早くなりました。これを基準にbcacheとfcacheを試していきます。
  • 新サイト(AWS t2.micro) + CloudFlare + KUSANAGI fcache
    • https://www.webpagetest.org/result/190508_4J_7b0928d6f924e8d4698b6753caeed8d1/
    • First Bytes 0.845s Fully Load 15.867s
    • おおー。確実に早くなりました。以下のようにF-CACHEにHITしたことがわかります。
  • 新サイト(AWS t2.micro) + CloudFlareなし + KUSANAGI fcache
    • https://www.webpagetest.org/result/190508_5W_8e0f63161b11d9fd14497d9f13b5a3b9/
    • First Bytes 0.588s Fully Load 18.046s
    • おー、CloudFlareなしfcacheオンリーだと、初速はめちゃめちゃ早いですね。
  • 新サイト(AWS t2.micro) + CloudFlare + KUSANAGI fcache + KUSANAGI bcache
    • https://www.webpagetest.org/result/190508_97_66422e4c559c1d51847abac508e88ba8/
    • First Bytes 0.892s Fully Load 15.231s
    • 初速は落ちましたね。けど、やっぱり他の静的コンテンツがCloudFlareのキャッシュから帰ってくるので、全体的なスピードはアップした、という感じでしょうか。
  • 新サイト(AWS t2.micro) + CloudFlareなし + KUSANAGI fcache + KUSANAGI bcache
    • https://www.webpagetest.org/result/190508_BD_ea283a342e16f40954704f80b313cff8/
    • First Bytes 0.614s Fully Load 18.451s
    • やはり初速は早いけど、全体的にはCloudFlareのCDNのほうが強いですね。
  • 新サイト(AWS t2.micro) + Incapsula(Static+Dynamicモード) + KUSANAGI fcache + KUSANAGI bcache
    • https://www.webpagetest.org/result/190511_A0_cda343e19da80c01960fe5d7d3c34170/
    • First Bytes 1.165s Fully Load 17.531s
    •  初速遅いけど判定は、Cですね。。
  • 新サイト(AWS t2.micro) + Incapsula(Static+Dynamicモード+Dynamic Content Acceleration(※)) + KUSANAGI fcache + KUSANAGI bcache
    • https://www.webpagetest.org/result/190511_R9_f82b1950e6e8f1b3d46e4dc9f0443109/
    • First Bytes 1.036s Fully Load 17.636s
    • Dynamic Content Acceleration機能です。今回はAWSのVPCがus-eastなので、アシュバーン?が最寄りでした。てか応答速っ。
  • 新サイト(AWS t2.micro) + CloudFlare + Incapsula(Static+Dynamicモード+Dynamic Content Acceleration(※)) + KUSANAGI fcache + KUSANAGI bcache
    • https://www.webpagetest.org/result/190512_KK_01657d85a38a8e24a91fbc0cc160285c/
    • First Bytes 1.033s Fully Load 13.971s
    • 初速ともにまぁまぁですね。一応両方ちゃんと通ってます。
      ※X-Iinfo: がNNNなので、Incapsulaのキャッシュはまだ効いてませんでした・・・けど、CloudFlareがHITしているので、結局AWSまでは取りには行ってないはず。
  • 新サイト(AWS t2.micro) + CloudFlare + Incapsula(Staticモード+Dynamic Content Acceleration(※)) + KUSANAGI fcache + KUSANAGI bcache
    • https://www.webpagetest.org/result/190512_M8_c66631c02506ebbda0a56be2d30fbda1/
    • First Bytes 1.312s Fully Load 14.404s
    • 一つ上とまぁ誤差ですね。
  • 新サイト(AWS t2.micro) + CloudFlare + Incapsula(キャッシュ無効+Dynamic Content Acceleration(※)) + KUSANAGI fcache + KUSANAGI bcache
    • https://www.webpagetest.org/result/190512_7E_1393ad66c4ae2ed3eb8490e5876edda1/
    • First Bytes 1.382s Fully Load 14.749s
    • 今これです。

ということで、初速は、CloudFlareなしで、KUSANAGIのfcacheが一番速い。
トータルは CloudFlare + Incapsula(Static+Dynamicモード+Dynamic Content Acceleration(※)) + KUSANAGI fcache + KUSANAGI bcacheが一番速いようです。

が、まぁ今回IncapsulaはBot制御目的ですし、2箇所でキャッシュ持つとややこしいので、キャッシュはCloudFlareだけにしました。

■CloudFlareとIncapsulaの多段構成について

多段構成のポイント?ですが、

Incapsulaを手前にすることは(おそらく無償版では)不可。
無償版IncapsulaはOriginにCNAMEが使えずIPアドレスしか使えない。

CloudFlareを前にする場合のポイント。(多分合ってると思う)

・CloudFlareに別のドメインを作ってそっちをIncapsulaに登録する
→同じ名前をCloudFlareとIncapsulaに存在すると以下のようなエラーになる。
※IncapsulaのProxyが名前解決したときに自分じゃない名前解決結果が来るから?と思われる。
→そんなことないです。それできなかったら導入前のhostsを使ったテストもできないので。(2019/05/26)

【2019/05/26 追記】

いろいろ間違ってます。普通にincapsulaにはwww.hits-net.comで登録してそのCNAMEをCloudFlareで向けつつCloudFlareのCDNを有効にすれば動きます。
↑のError code 23の原因にはサポートとも確認しましたが、結局わからずじまいで、なぜか今日改めて試したらうまくいきました。

CNAME reuseの機能を活用して、CloudFlareの本丸ドメインをCNAMEでIncapsulaに向ける。
→Incapsulaにはxxx.hits-net.comで登録してるけど、そこで払い出されたCNAMEをwww.hits-net.comに向けてさらにCloudFlareのCDNとDNSをオンにして、多段にしました。

 

■リダイレクトの初速を上げる

いま「/blog」へのリダイレクトは、cloudflareがやってる・・・と思う。

 

【2019/5/12追記】

何故かIncapsulaが時折古いオリジン(旧オンプレ)に転送してしまう謎現象が発生したので切り戻しました。
今はCloudFlareオンリーです。

このX.X.X.100っていまいま設定上どこにもないんですよねー。

同じドメインを何度か消したり入れたりしてるから一部のPoPにゴミ情報のこったかなぁ。

まいったなぁ。てかよく見たらCNAME Reuseって

Note: Available for Enterprise plan customers only.

あちゃー。

【2019/05/26 追記】
結局のところ、原因不明です。多分やっぱり古い情報持ってたとしか思えないですね。
上述の通りサポートともいろいろやりとりして、Incapsulaのサイト登録もやり直しましたが、結局原因不明で時間が解決したか、何らかのIncapsula側のメンテナンスで直ったとかそんな感じですね。

【2019/05/27 追記】
CloudFlareとIncapsulaの多段化はやはり無理でした。
令和になったことだしクラウドへ移行する – 10 – CloudFlare+Incapsulaの多段化はやっぱり無理

 

【バックナンバー】

ではでは。またの機会に。

令和になったことだしクラウドへ移行する – 8 – t2.microが激重になる

ども。こんばんは。

mariaDB問題は解決して、ようやく落ち着いたかと思ったら、今日はなぜかブログが激重になりました。。。

で、調べてみると、st(steal)が上昇していました。

今まで意識したことがなかったのですが、st値は、

【EC2】CPU使用率のsteal項目とは

馴染みがない項目だったのでで詳細を調べてみると、仮想サーバにおいて
「ゲストOSに処理を要求をしても、CPUリソースを割り当てられなかった時間の割合」
を意味するとのことです。

らしいです。で実際こんな感じでstが80%消費されており、実質20%しかCPUが使えない?状態のようです。

そりゃ重いわな。

AWSコンソールで、CPUクレジットを見ていると、クレジット使い切っちゃったみたいですね。

t2.microのCPUクレジットは144です。
※t3.microはほぼ値段一緒なのにCPUクレジットが多いんですよねー。やっぱt3にしたいなぁ。

バースト可能パフォーマンスインスタンスの CPU クレジットおよびベースラインパフォーマンス

とりあえず、インスタンスを再起動するとリセットされるようなのでその場しのぎですが再起動しました。

うーん。なかなかクラウドならではですねぇ。

これKUSANAGIのbcacheとか効かせたら処理減って軽くなるのかなぁ。とりあえず明日一日様子見ですね。

確かにちょっとアクセスおおかったのかなぁ。。。

 

【バックナンバー】

ではでは。またの機会に。

 

令和になったことだしクラウドへ移行する – 7 – t2.microでmariaDBが落ちる

ども。こんばんは。

昨日以降したAWS環境ですが早速トラブルです。

というかまぁ起きそうだなぁとは思ってましたが、メモリが足りずmariaDBが落ちてました。

[root@kusanagi80 blog]# more /var/log/mysql/mysqld.log

2019-05-06 10:23:26 140552243030272 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: The InnoDB memory heap is disabled
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: Compressed tables use zlib 1.2.7
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: Using Linux native AIO
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: Using SSE crc32 instructions
2019-05-06 10:23:26 140552243030272 [Note] InnoDB: Initializing buffer pool, size = 384.0M
InnoDB: mmap(421724160 bytes) failed; errno 12
2019-05-06 10:23:26 140552243030272 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
2019-05-06 10:23:26 140552243030272 [ERROR] Plugin ‘InnoDB’ init function returned error.
2019-05-06 10:23:26 140552243030272 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
2019-05-06 10:23:26 140552243030272 [Note] Plugin ‘FEEDBACK’ is disabled.
2019-05-06 10:23:26 140552243030272 [ERROR] Unknown/unsupported storage engine: InnoDB
2019-05-06 10:23:26 140552243030272 [ERROR] Aborting

確かにちょいとメモリが足りないしswapがないんですよねー。

[root@kusanagi80 blog]# free -m

              total        used        free      shared  buff/cache   available
Mem:            989         678          73          76         237          81
Swap:             0           0           0

にいろんな方も同じ状況みたいで、swapを作る方法がありました。
t2.microでもssdだし、swap作っても大丈夫?かな。

参考:AWSのMySQLがよく落ちるのを解決 「Failed to start MariaDB」「InnoDB: Cannot allocate memory for the buffer pool」

手順は上記の参考サイトの通りですが、最後にfstabにも書きます(そうしないと起動時にswapがマウントされないので)

 

[root@kusanagi80 blog]# sudo dd if=/dev/zero of=/swapfile bs=1M count=1024

1024+0 レコード入力
1024+0 レコード出力
1073741824 バイト (1.1 GB) コピーされました、 35.3172 秒、 30.4 MB/秒

[root@kusanagi80 blog]# sudo mkswap /swapfile
スワップ空間バージョン1を設定します、サイズ = 1048572 KiB
ラベルはありません, UUID=81d4b5f0-bf32-4ea1-a3f5-3c4eaf7926a4
[root@kusanagi80 blog]# sudo swapon /swapfile
swapon: /swapfile: 安全でない権限 0644 を持ちます。 0600 がお勧めです。
[root@kusanagi80 blog]# sudo chmod 600 /swapfile
[root@kusanagi80 blog]# free -m

              total        used        free      shared  buff/cache   available

Mem:            989         670          83          76         235          92
Swap:          1023           0        1023

SWAPでけたー。仕上げにfstabに書いて、rebootしてswapできてたからokかな。

/swapfile swap swap defaults 0 0

さぁ、これで様子見ですね。

【追記】

また落ちました・・・。
2019年 GWの振り返り」の公開後、多分クローラーからのアクセスとかで落ちたっぽいです。
ロードアベレージが偉いことになってたのと、swapも結構浸かってしまってました。
参ったな。

以下ぱっと見た時のリソース。

こっからガッとswapへりました。多分mariaDB落ちたと思う。
※この手前でもしかしたらswap食い尽くしてたかも。

[root@kusanagi80 blog]# free -m

              total        used        free      shared  buff/cache   available
Mem:            989         857          66          10          65          12
Swap:          1023         620         403

top

top – 18:33:51 up  2:23,  1 user,  load average: 24.80, 14.64, 5.86
Tasks: 103 total,   1 running, 101 sleeping,   0 stopped,   1 zombie
%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  1013192 total,   842544 free,    56472 used,   114176 buff/cache
KiB Swap:  1048572 total,   996736 free,    51836 used.   814284 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND  
9125 root      20   0  559436  23724  18016 S  0.0  2.3   0:00.04 php-fpm  
9130 httpd     20   0  559436   6812   1104 S  0.0  0.7   0:00.00 php-fpm  
9131 httpd     20   0  559436   6812   1104 S  0.0  0.7   0:00.00 php-fpm  
9132 httpd     20   0  559436   6812   1104 S  0.0  0.7   0:00.00 php-fpm  
9133 httpd     20   0  559436   6812   1104 S  0.0  0.7   0:00.00 php-fpm  
9134 httpd     20   0  559436   6812   1104 S  0.0  0.7   0:00.00 php-fpm  
9135 httpd     20   0  559436   6812   1104 S  0.0  0.7   0:00.00 php-fpm  
9126 httpd     20   0  559436   6808   1100 S  0.0  0.7   0:00.00 php-fpm  
9127 httpd     20   0  559436   6808   1100 S  0.0  0.7   0:00.00 php-fpm  
9128 httpd     20   0  559436   6808   1100 S  0.0  0.7   0:00.00 php-fpm  
9129 httpd     20   0  559436   6808   1100 S  0.0  0.7   0:00.00 php-fpm  
9106 httpd     20   0  126160   5240    908 S  0.0  0.5   0:00.00 nginx    
9107 httpd     20   0  124956   3680    856 S  0.0  0.4   0:00.00 nginx    
9108 httpd     20   0  124956   3680    856 S  0.0  0.4   0:00.00 nginx    
9105 root      20   0  124952   3004    392 S  0.0  0.3   0:00.00 nginx       
    1 root      20   0  191120   2496   1516 S  0.0  0.2   0:03.30 systemd  
9145 root      20   0  161880   2204   1564 R  0.0  0.2   0:00.00 top

ちょっと参ったな。swap2GBに増やしてみたので、これで様子見ですかねー。

 

 

【バックナンバー】

ではでは。またの機会に。

令和になったことだしクラウドへ移行する – 6 – ブログがAWSになりました。

ども。こんばんは。

件名のとおりです。

いろいろありつつ、半日でなんとか終わりました。

多分見れてるはず。です。

もちろんCloudFlare越しですが。

awsは12ヶ月無料枠のt2.microでKUSANAGIを入れました。
※KUSANAGIの推奨はメモリ4GB以上ですが、まぁこのくらいの規模なら全然余裕ですね。きっと。

ただ、KUSANAGIの全力は出てないと思いますが、前よりはキャッシュはCloudFlareのキャッシュも効いているはず。

疲れた。

途中経過は概ねログと画面キャプチャがあるのですが、もうありふれた話ばかりなので今回はポイントだけを自分用にメモです。

  • AWS
    • 普通にセットアップ、管理者のMFAを有効にしたくらい
    • あと一応請求が$10超えたらメール来るようにしてみた。
    • VPC
      • リージョンは最安で米国東部(バージニア)
        • どうせCloudFlare通すしきっといい感じになる。。。とおもう。
      • アベイラビリティゾーンはus-east-1f
    • EC2
      • インスタンスはt2.micro
        • 本当はt3にしたかったが、AMIのKUSANAGIが対応していなかった
      • Elastic IP一つ取得
    • KUSGANAGI
      • とりあえずyumで諸々アップデートしてから設定
      • php7だとうちの古めかしいvistaテーマが動かない&諸々エラーが出たのでphp5.6に戻した(kusanagi initやりなおし)。
      • サブディレクトリにWordPressを展開しているので多分効いてないKUSANAGIの機能がある気がする。
      • bcacheを効かせるには、多分以下の設定いれればいけるかも?
      • てか、KUSANAGIってそれ用のWordPressプラグインあるっぽいけどそのへんよくわかんない
      • あと、サブディレクトリに入れた関係か多分Let’s Encryptちゃんと動いてないと思う。
    • 引っ越しの仕方
      • BackWPupプラグインでファイルもDBの抜こうとしたが、旧環境だとPHPが2GB以上のファイルをP扱えなくてエラー(PHPバージョンで扱えない大きさのアーカイブになります。)でアーカイブがコケまくったので諦めた。
        • 一応古いPHPで2GB以上のファイルが扱えないことはないが再コンパイルなんて今さらやってられないのでスルー。
      • wp-contents配下をtgzで固めてscpでゴリゴリコピーした。
      • KUSANAGIのデフォルトのドキュメントルートをまるまる「/blog」にコピーしてwp-contentsだけ上書き。
      • DBはBackWPupで抜いたものをmysqlコマンドでどーん。
    • 心残りというか明日以降確認
      • KUSANAGIのサブディレクトリ化もう少し見直す
      • SSL化する?(Cloudflareの機能でもいいかも)
      • キャッシュのテスト
      • メールでDBのバックアップ飛ばしてるけど、多分動かないだろうなぁ。
      • ちと、ポートスキャンとか外部からのアクセス確認をば。セキュリティグループはしっかり作ったはず。
      • Google Analyticsとか大丈夫だと思うけど、明日確認
    • いずれやりたい
      • せっかくAWSのアカウント作ったし、BackWPupはS3にバックアップ取れるので、バックアップの方式を検討する

そんなところかな。

【追記】

やっぱりへんだなぁーと思ってたらやりがちなことをやってしまっていた。
参考:KUSANAGIに移設する際の5つの手順をまとめてみた

ここでの注意点は移設先のwp-content内にあるmu-pluginsを削除してしまわない事。
よくあるのがwp-contentをリネームしてまるっと置き換える方法。これやっちゃうとKUSANAGI用のオリジナルプラグインがなくなっちゃいますので、リネームしたディレクトリから移しておきましょう。

KUSANAGI用のオリジナルプラグインはWordPressの高速化の一端を担っています。
多言語に対応したWordPressが日本語で表示できるのは当たり前ですが、この翻訳が管理画面なども遅くする原因にもなっています。ですので、翻訳ファイルをキャッシュしてしまうことでWordPressの高速化を図っています。

なせ、オリジナルプラグインなのか。それはWordPressのコアを修正したりしないためです。
良く勘違いされるのがKUSANAGIで導入されたWordPressはチューニング(改造)されていると言う間違いですね。これやっちゃうとバージョンアップできなくなるので絶対やりません。

 

これで、Azure、Office365、AWSとGCPもちょっとだけ(AIY Voice Kitで)やったので、主要なクラウドには手が広げられたかなぁ。

以下画像アップロードテスト。

連休中に、メールとWebのクラウド化が無事完了したε-(´∀`*)ホッ

これで、なんと我が家のFWでは外部→内部を処理するルールがなくなってしまう&監視するものがなくなってしまう。。

それはそれで少しさみしいですね。
とはいえ、まだオンプレでもいろいろやりたいことはあるかなー。

【バックナンバー】

ではでは。またの機会に。

令和になったことだしクラウドへ移行する – 5 – Exchange Server 2010 to Office 365(4)

ども。こんばんは。

気づけばもう連休もあと1日半です・・・。

昨日はずっと寝てたのと、今日も夕方まで寝てしまったので、さっさと続きをやります。

とりあえず、前回の残タスクの通り、ライセンス節約のため個人メールボックスを共有メールボックスに変換します。

やり方はこんな感じ。

ユーザー メールボックスを共有メールボックスに変換する

  • 変換するユーザーメールボックスには、共有メールボックスに変換する前に割り当てられたライセンスが必要です。 そうでない場合、変換オプションがメールボックスに表示されません。ライセンスを削除した場合、メールボックスを変換するために再度それを戻す必要があります。 ライセンスは、メールボックスを共有に変換した後に、ユーザー アカウントから削除できます。
  • 共有メールボックスは、ライセンスなしで、最大 50 GB のデータを保持することができます。 これ以上のデータを保持するには、ライセンスを割り当てる必要があります。 ライセンスを削除するには、(添付ファイルがあるものなど) 大きなメールを多数削除してサイズを小さくする必要があります。
  • 古いユーザー アカウントは削除しないでください。 それは共有メールボックスの固定に必要です。 ユーザー アカウントを既に削除している場合、「削除済みユーザーのメールボックスを変換する」 (削除されたユーザーのメールボックスを変換する) を参照してください。

ポイントとしては、上記の3点ですね。特に3つ目。読んでなかったら確実に消してたわ。

【追記:やらかした】
やかしました。多分大丈夫ですが、上記のサイトの下の方にこんなことが書いてあります。
もしかしたら、またユーザメールボックスに戻される・・・のかも???うーん・・・。まぁいっか。
強くお勧めするならもっと上に書いておいてほしかったです。。。

ハイブリッド環境でユーザーのメールボックスを変換する

この共有メールボックスがハイブリッド環境にある場合は、ユーザーのメールボックスをオンプレミスに戻して、ユーザーのメールボックスを共有メールボックスに変換してから、共有メールボックスをクラウドに戻すことを強くお勧めします。

その理由は次のとおりです。クラウド内のメールボックスを変換すると、そのメールボックスは変換されますが、新しい現実はオンプレミスに同期されないため、オンプレミスではメールボックスがユーザーのメールボックスであると見なされます。

通常、これは問題ではありませんが、オンプレミスの属性 (メールボックスがユーザーのメールボックスであると考えられる) が新しいクラウドバージョンの属性を上書きする可能性があるため、その結果、メールボックスの変換が行われる場合があります。 ユーザーメールボックスがライセンスを必要とするか、30日後に削除された場合は、この問題が発生します。

これが発生する理由のほとんどが解決されましたが、これはまだ発生する可能性があります。 安全にして、メールボックスをオンプレミスに戻すことをお勧めします。

あと、やっぱりいきなり契約せず評価ライセンスではじめてほんとに良かった。移行するにしてもライセンスが最初は必要になるんですね。

ちなみに、ちゃんと ハイブリッド構成にしたおかげて?権限も移行できてるので、ちゃんとメインで使う予定のユーザは他のメールボックスを開くことはできます。(フルアクセセスを与えており、ちゃんと引き継がれた。さすがハイブリッド!)

でもやりたいのはこうじゃないし、それぞれのボックスの所有者でログインしたり、それぞれの予定表を作る予定もなく、あくまで、システム通知やSNS系のメールの受け用のボックスがほしいのです。

参考:オンプレExchange時代の運用

で、後悔しないように改めてこちらの記事も読んでみました。うん、今回はやっぱり共有メールボックスが正しい・・はず!

参考:Office365「共有メールボックス」とは

■ユーザメールボックスを共有メールボックスに変換する

早速やってみます。

Exchange管理センターから該当メールボックスをポチッと。

はいはい。

即効でおわります。数秒。

この時点では、ライセンスを停止してない?ので、まだ元のメールボックスの所有者でログインしてOWAでメールが見えるっぽいですね。

もう一つ変換対象があるので、そっちも同様の手順でやります。(10GBくらいあるボックスだったのですが、2分くらいで終わりました。)

無事共有に変換できました。

とりあえず、OWA上で追加してみる。

メインのアカウント上で自分の名前を右クリックして「共有フォルダーの追加」をクリックします。

あとは選ぶだけ。(「他のメールボックスを開く…」と要領は同じですね。)

最終的にこんな感じになりました。

とりあえず、送受信テストしてみます。

あれ、差出人が共有メールボックスにできないですねー。

うーん。フルコントロールなんだけどなー。

一応権限つけてみました。

だめですねー。候補に出てこない。

念の為、「他のメールボックスを開く…」でやってみたところ・・・・

このメールボックスからメッセージを送信するためのアクセス許可がありません。

えー。うそんフルコンやし、ちゃんと送信する権限もつけたけどなー。反映に時間かかるのかなー。

まぁいいわ。別に。そのうちなんとかなるでしょう。「メールボックス所有者として送信する」の権限は必須ぽいので。

ちょっと先に進めます。

■ライセンスを剥奪して、サインインも禁止する!

これで、共有メールボックス化が無事できたので、旧ユーザからはライセンスを剥奪します。
あと、サインアップ時に作った「.onmicrosoft.com」もライセンス剥奪してみます。

また、ADから引っ越してきたユーザはパスワードがボロい可能性も大いにあるので、サインインも禁止します。

さらばライセンス。

ちなみにいいかどうか知りませんが、onmicrosoftのアカウントもライセンス剥奪しました。

これで、ライセンスを持っているのは1人のみになりました。

ちなみにライセンスを剥奪したユーザでログインしてみました。

おー、空っぽですね。

で、一応今回ADと同期してはいますが、余計なユーザはOffice365にサインインできないようにしてみます。
※onmicrosoft,comのユーザは念の為、ライセンスは剥奪しましたが、サインインは可能にしてあります。もちろん別で全体管理者は設定済み&サインアップ時の連絡先は、ライセンス付与済みユーザにしています。

 


【2019/05/05 追記】

勢い余って、Azure AD Connectに必要な同期用ユーザまでサインイン禁止にしてしまったみたいです。

なので、「Sync_[サーバ名]_[ランダム?]@hitsnetcom.onmicrosoft.com」はサインインを有効にしてあげたら治りました。

これでsyncしたら、ブロックしたユーザまたサインイン許可に戻ってしまった・・・

うーん。やっぱりAD側でログイン無効化して同期させるのが正しいんだろうけど、やだなーこれ。課題ですね。

 


 

 

で、サインイン禁止したユーザで入ってみたところ。
※てかID・PWの確認はできてしまう気がする。。。。。。

↑これは反映中だったみたいです。しばらくするとこうなります。

とはいえ、アカウントの存在とパスワードが正しいことはバレちゃいますねこれ。まぁいいか。。

Azureも一緒にかわるっぽい?(←もともとこのユーザサインインできてたか未確認です)

さぁ、だいたいできた。

■正規のライセンスを買って割り当てる

まだ評価期間は残っていますが、このっている今だからこそ正規版を買います。
※そしたら、何かあっても、最悪評価版に割り当て直して調査できる猶予がある!はず・・・。

いきなり1年契約でかいます。

住所とかを入れます。

年間¥6,998です。

何故かシークレットモードのブラウザだと手順3にいけませんでしたのでやり直し。。。

支払い方法を入れます。

かいましたー。

無事追加。

ライセンスを割り当て直します。

試用版をoffにして購入した方をonにします。

個別の機能でのon/offもできるんですね。

できましたー。

ちゃんとライセンス数が更新されていますね。

一応請求書などのメール連絡先も確認します。
予定通り、追加しておいた全体管理者が有効になっており、onmicrosoftの方の連絡先メールアドレスもライセンスのあるユーザになっています。
これならonmicrosoftにはライセンスなくても大丈夫・・・だと思います。

おまけ。ライセンス変更前後のサインイン後の画面。
ちょっとへりました。

■仕上げ:DNSレコードの変更(外部向け)

さて、ここまででもう準備は終わったのでいよいよDNSレコードの向き先を変えます。

とりあえず、CSVでエクスポートもしていたのですが、MXとCNAMEをいれます。

途中の画面を取り忘れましたが、チェックする機能があります。
終わったら確認を押すと以下のようにOKになります。

管理のドメインから状況が確認できます。
おっと、一つカスタムドメインのDNS設定が漏れていましたね。困りはしないのですが一応いれます。

使うサービスを選びます。(これによって向け先に出てくるレコードが変わるみたいですね。Exchangeなら基本MXとautodiscover用のCNAMEとSPFだけとか。)

Exchangeだけえんだので、3つだけです。
※ただし、見切れてますがこの画面上にあるエクスポート機能でエクスポートすると全サービス分のレコードがCSVででてきます。

はい。おわりました!

ちなみに今回SPFレコードは、Office365に加え、自宅の固定IPアドレスも残しています。
それでもチェック結果はOKだったので問題ないと思われます。

■仕上げ:DNSレコード+Postfixのtransportの変更(内部向け)

ここからは内部向けの話なので、関係ない人はここまでで晴れてOffice365ユーザとして利用可能になります!

さて、うちの場合は、

内部DNSサーバのMXレコード修正と、内部用メールをtransportでオンプレExchangeに向けている部分を修正します。

ありふれた手順なので省略します。reloadとかpostmapとか忘れないでね。

ということで、経路がこうなりました。
(この辺ももうリプレースしないとですね。)

内部サーバ->オンプレExchange->ハイブリッド構成->o365

内部サーバ->o365
※ここはTLSにしたいところだけど、面倒くさいのでやめました。

ちなみに、これは主に内部サーバのシステム通知系なので、自ドメイン以外には送信しません。
※内部ですけど、外から来るメールと同じ扱いにしました。

【メモ】
Zabbixの通知先に携帯キャリアメールが入っている。今はオンプレPostfixにSMTPを向けているがこれをo365に変更するときは、うちでも設定が必要。
各種サーバは全体的にSmartRelayでo365にむけないとなぁ。

なので、o365用のMXレコード宛に送りつけるだけです。自ドメイン以外の外部に送る場合は、認証がいるはずです。

この辺を参考にしてみてください。

Office 365 を使用してメールを送信するように多機能デバイスまたはアプリケーションをセット アップする方法

※昔は性的なグローバルIPアドレスを認証条件にできたけど、いつからかTLSで証明書入れるの必須にならなかったけ。

さて、あとはインターネットからメールサーバ宛の25/tcpを閉じれば終わりですね。

TTLも300だしもうとっくに伝播したと思いますが、一応旧メールサーバのmaillogを流しながら、全アドレスにテストメールを送信して、旧サーバに回っていないことを確認しました。

というかこの時点でもまだ、差出人が共有メールボックスにできないです。この記事を書いている間に数時間経過したのですが・・・。まぁそれは別の課題で。。。

ということで、一旦終わりです。

あとは細かなタスクとして・・・

  • macOSのメールアプリで共有メールボックスにアクセスする
  • 古いサーバのメールの向き先変更(snmptrapのメール変換とかもそろそろやめたい・・・)
  • Zabbixの通知メールサーバ変更(宛先にキャリアメールが入っているので注意)
  • 各種アプライアンスのメール通知先とか見直し

そんなところかな。あーWebサーバの移行できるかなぁ。

【バックナンバー】

ではでは。またの機会に。