X



【GMO】XREA/CORESERVER/VALUE SERVER 4台目

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん@お腹いっぱい。
垢版 |
2017/11/16(木) 21:38:03.250
デジロック(GMO傘下)の提供するレンタルサーバーサービスについてのスレ。

過去スレ
【GMO】XREA/CORESERVER/VALUE SERVER 3台目
http://mevius.5ch.net/test/read.cgi/hosting/1419253436/
【GMO/デジロック】xrea/core/valu Part2
http://peace.5ch.net/test/read.cgi/hosting/1386097192/
【GMO/デジロック】XREA/CORE SERVER/VALUE SERVER
http://toro.5ch.net/test/read.cgi/hosting/1369588489/
0165名無しさん@お腹いっぱい。
垢版 |
2019/11/02(土) 14:53:48.700
うちもCORESERVERで巻き込まれた
10年ぐらいは使ってきたけど、ちょっと前にCORESERVER中身リプレースしたくせに
この体たらくでは、次の更新はないな
うちは幸い大きな被害はないけど、被害に遭ってからでは困るのでな
0166名無しさん@お腹いっぱい。
垢版 |
2019/11/02(土) 15:00:38.990
RAIDは組んでいるという記載だったはずだ
ただ「RAID=バックアップ」ではないというのは知られた話
そもそもRAIDをちゃんとやっていてのディスクトラブルならば、そんなのは想定内であって、サーバーの停止を伴うのはおかしい
だからRAIDアレイが壊れたか、コントローラの故障とかだろう
それならば、バックアップがなければ復元は極めて困難だ
0168名無しさん@お腹いっぱい。
垢版 |
2019/11/02(土) 16:07:05.010
障害のページ見て気付いたけど、バリューサーバーより
コアサーバーの方が全体の障害多いんだね。鯖数に対する比率で見ても多い。
何が違うんだろ?
0169名無しさん@お腹いっぱい。
垢版 |
2019/11/02(土) 16:19:02.000
RAIDがどうこうとかいう個別ハードの話じゃないんだろう?
同時多発でぶっ壊れていくのが恐ろしいと思う
0176名無しさん@お腹いっぱい。
垢版 |
2019/11/04(月) 17:06:59.650
とりあえず6月までは戻してもらえた。
そこからプラグインで復元できればOKなんだけど、
頻繁に500エラーが出て復元できない・・・
もうこの鯖ダメなんじゃね(´・ω・`)
0180名無しさん@お腹いっぱい。
垢版 |
2019/11/05(火) 18:11:35.810
詫び代は1カ月分の費用無料だってさ。
バックアップ取ってない人は6月以降のデータを諦めるしか無さそう。
0183名無しさん@お腹いっぱい。
垢版 |
2019/11/06(水) 00:14:30.050
新サーバーに移行しろって誰がするんじゃボケ
はやくDBを戻してくれよ・・・
0185名無しさん@お腹いっぱい。
垢版 |
2019/11/06(水) 09:33:34.640
1ヶ月無料はいいとして、新サーバーへのデータ移行ってなんやねん
「新」じゃなくて「別」だろ

移行したら移行したで、こんどはそっちが壊れる番かもしれないだろ
だって今のサーバーがこんな長期停止するような欠陥構成でポンコツなわけだから、
他のサーバーだって同様の構成で、同様のトラブルに陥る可能性が十分あることになる
むしろやるべきは、今のサーバーを機材総入れ替えしてさっさとデータをリストアすることだろうが
0192名無しさん@お腹いっぱい。
垢版 |
2019/11/09(土) 14:43:21.970
7日で作業終わったみたいになってるけどまだDB復旧してないんだけど
0193名無しさん@お腹いっぱい。
垢版 |
2019/11/09(土) 16:53:47.400
たまにはこういうぶっ飛び事件が無いとスレが盛り上がらない
0195名無しさん@お腹いっぱい。
垢版 |
2019/11/09(土) 22:45:06.780
こんなやる気のないサーバー会社は始めて
2度と使わない
ゴミサーバー
0196名無しさん@お腹いっぱい。
垢版 |
2019/11/10(日) 07:30:27.740
RAIDが壊れてバックアップから復旧しようとしたらそれもデータが壊れてて一部ユーザは復旧不可能です。ごめんなさいm(_ _)m

ひと昔前の個人運営DQN鯖並みの対応w
0197名無しさん@お腹いっぱい。
垢版 |
2019/11/10(日) 08:35:27.360
「6月5日までのデータしかなかったです」
それはいいからはよ6月5日までのデータに戻せよ
障害おこして何日過ぎてんねんと
お前ら仕事してんのかボケ
0198名無しさん@お腹いっぱい。
垢版 |
2019/11/10(日) 08:39:16.330
管理画面にすら繋がらない (-_-)ヤレヤレダゼ
0199名無しさん@お腹いっぱい。
垢版 |
2019/11/10(日) 08:40:41.140
2019/11/10(日) 21:00 〜 2019/11/11(月) 09:00にメンテってことはそれ以前はつながるってことなんじゃねーの?
0200名無しさん@お腹いっぱい。
垢版 |
2019/11/10(日) 08:42:37.150
まさか独自ドメインの再設定からやらされる羽目になったりして
0203名無しさん@お腹いっぱい。
垢版 |
2019/11/10(日) 16:25:53.910
>>199
障害があったサーバーだけ、また高負荷状態になってる。
メンテ前に色々作業しておきたかったが、どうにもならんね(´・ω・`)
0206名無しさん@お腹いっぱい。
垢版 |
2019/11/11(月) 00:12:29.910
過去のメール引っ張り出してきたら、2017年9月頃にマイグレーションと称して一新したばかりだったじゃん
その新構成が2年程度でぶっ壊れて復旧不可能というのはどうなっとるんじゃ
2年前のメールには
「移行を行う新サーバーは、現状よりも高性能かつセキュリティに
 優れたものとなりますので、今まで以上に快適にご利用いただけます。」
と書いてあったのは何だったのか。高性能とは???

このマイグレーションとやらをやってなかったら、ボロ構成でも壊れはしなかったのではないか?
まぁそれはわからんが、前の構成が壊れずに済んだから、新構成ではバックアップをケチったとか?
バックアップの出番がなかったから要らないだろwとか言って削減したのではあるまいな?
0207名無しさん@お腹いっぱい。
垢版 |
2019/11/11(月) 09:45:53.670
酷い会社だなぁ
0209名無しさん@お腹いっぱい。
垢版 |
2019/11/11(月) 10:54:28.250
結局、こっちがDB再作成 10/1のデータでリストア (-_-)ヤレヤレダゼ
0211名無しさん@お腹いっぱい。
垢版 |
2019/11/11(月) 11:30:11.310
これってDBの移行は自分でやれっていうことなの?
0213名無しさん@お腹いっぱい。
垢版 |
2019/11/11(月) 12:14:46.600
9:00にメンテ終わる予定で終了の連絡もなし
10:00にDB見たらすべてないのでDBを作成し過去のデータでレストア
12:00にみたら他のDBが復活してる *10;00に作ったのは無駄というか復活してない
12:00のDBの中身が復活してるかを見ようとphpMyAdminログインするも使えず ←今ここ
0214名無しさん@お腹いっぱい。
垢版 |
2019/11/11(月) 12:20:57.180
あっphpMyAdmin見れたけど6月頭までのデータだわ
0215名無しさん@お腹いっぱい。
垢版 |
2019/11/11(月) 12:25:14.040
なんなんだこのクソ会社 報告しろや
0216名無しさん@お腹いっぱい。
垢版 |
2019/11/11(月) 12:41:02.280
[2019/11/11 12:20]
m34.coreserver.jp
m48.coreserver.jp
s72.coreserver.jp
において、DB移行に不具合がございましたが、修正完了いたしました。

だって
0226名無しさん@お腹いっぱい。
垢版 |
2019/12/09(月) 13:16:59.930
>>222
https://www.coreserver.jp/info/2019/20191106.php
に「RAIDを構成するSSD 12台構成のうち複数台で故障が発生」ってあるから、
その可能性が高いかもな。SSDが複数台ほぼ同時に壊れるなんてよっぽど運が悪い可能性もあるけど、
SSDのロット不良か設計不良ってとこだろ。
SSDがほぼ同時に複数壊れる可能性まで考慮して構成しろってのはやや酷に思われる。
ただ、最新のバックアップが2019年6月ってのはいただけない・・・気もするが、
そもそも、CORESERVERはRAIDを組んでるとは書いてあったが、定期的にバックアップ取ってますよとはどこにも書いてないので、
それはそれぞれのユーザーがなんとかすべきだったという主張もできるだろう。

>>222のせいならばどこ製とか具体的に書かなくても「SSDのファームウェアの不具合に起因するトラブルであることが判明しました」とか書いてもらえれば、
まぁ、GMO / CORESERVER側のせいじゃないねってことにもなるが、言い訳と見なすユーザーもいるかもしれないね。
0227名無しさん@お腹いっぱい。
垢版 |
2019/12/10(火) 16:58:56.820
また大規模障害
今度は自分も当たっちまった
0229名無しさん@お腹いっぱい。
垢版 |
2019/12/13(金) 00:39:20.240
自分もcoreserver契約してて障害には当たらなかったけどいずれは同じようになりそうだな
で5年以上分払っちゃってるから逃れられない
0233名無しさん@お腹いっぱい。
垢版 |
2019/12/27(金) 09:08:14.370
ほんとうに怖い。さくらのレンタルサーバー
https://megalodon.jp/2019-1225-1156-39/https://qiita.com:443/unico/items/76499d1e20042d929aa1
さくらで専用サーバーを10年ほど利用しています。
単体のハードを利用するもので、外部からの操作はsshでログインすることしかできないものです。

さくらのレンタルサーバーを利用することは、ほんとうに危険で怖いことだとおもいます。
0235名無しさん@お腹いっぱい。
垢版 |
2019/12/27(金) 12:49:39.730
この前のDBのぶっ飛びでさくら移動も考えてたが、BIOSの入り方もわからない奴が作業するのか…
移らなくてよかった
0236名無しさん@お腹いっぱい。
垢版 |
2019/12/27(金) 13:00:57.400
結局どこも素人がいじってるってことだわな
0237名無しさん@お腹いっぱい。
垢版 |
2019/12/27(金) 19:22:50.700
昔は謝りすぎるくらい謝ってる所が多かったが、今はもう何があっても謝らないって所ばかりになった。
0247名無しさん@お腹いっぱい。
垢版 |
2020/01/31(金) 18:02:14.830
>244 の障害

[2020/01/29 06:20] WEBアクセス障害
[2020/01/29 07:20] 対応が終了いたしました。ご迷惑をおかけし申し訳ございませんでした。
[2020/01/29 17:40] 再発を確認しましたので、再度調査・対応中です。


今の時点で続報なし、現状でどうなってるんだろ

○現在の復旧への取り組み状況:
技術部門に報告済み
対応中

のままってことは、トラブル調査を継続していてまだ復旧宣言を出せる状態じゃないのかな
0249名無しさん@お腹いっぱい。
垢版 |
2020/02/05(水) 10:44:40.750
未だに解決して無くてワロタ

[2020/01/29 07:20] 対応が終了いたしました。ご迷惑をおかけし申し訳ございませんでした。
[2020/01/29 17:40] 再発を確認しましたので、再度調査・対応中です。
ご迷惑をおかけしますが、よろしくお願いいたします。

[2020/02/03 16:40] お世話になっております。
下記の予定でメンテナンスを行います。
○時刻:2020/02/04 01:00 〜 03:00 の間
○影響範囲:30 分程度、全サービス停止
ご迷惑をおかけしますが、何卒よろしくお願い申し上げます。

[2020/02/04 02:10] 作業が完了いたしました。長々とご迷惑をおかけし申し訳ございませんでした。
[2020/02/05 10:00] 高負荷状態が継続しておりますので、引き続き調査中です。
ご迷惑をおかけしますが、何卒よろしくお願い申し上げます。
0251名無しさん@お腹いっぱい。
垢版 |
2020/02/05(水) 16:20:33.220
自分が >>132 >>133 で報告してる挙動だけど、
再起動後に数時間してから発生する恐怖のハングタイムがある

数時間で抜けるんだが、CPU負荷が 2000 超えるレベルで
基本全ての処理は正常に終わらない (通常1秒以内に終わる処理が5分後におわったりする)

1台のハードウェアに20ぐらいのサーバが仮想的に入ってる構成のはずだが
起動してから1時間おきに1台ずつ有効化 みたいな形でやらないと乗り越えられないのではと推測する
どのサーバに悪さする要因がいるかも切り分けられてなさそうだし
0253名無しさん@お腹いっぱい。
垢版 |
2020/02/06(木) 11:29:35.220
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
0263名無しさん@お腹いっぱい。
垢版 |
2020/02/13(木) 16:43:50.240
>[2020/02/06 11:50] ストレージ I/O の負荷が高いため、外部からの CMSへのアクセス等、随時高負荷の制限を行っております。
>また、根本的対策として、負荷を分散のため、機器増設を検討しております。
>ご迷惑をおかけしますが、何卒よろしくお願い申し上げます。

1/29から障害起こして2/6を最後に在宅勤務に移行して放置w
すげえ会社だな。
0264名無しさん@お腹いっぱい。
垢版 |
2020/02/13(木) 20:36:51.920
何度か自分が書いてるけど再起動した後の数時間後に突然発生する恐怖の山を越えれば落ち着くという挙動
今回のサーバはそれが起動して4日と12時間ほど経過した 2/10 16:00〜17:00 に訪れて、
それが終わった後は、おそらく全サーバ筐体の中で負荷が一番低いサーバとして安定稼働するようになってる

それ以降はロードアベレージが20前後で80時間近く快適そのもの

おそらくハードウェア交換やメンテはやらないものと思われる(挙動から見て原因はハードじゃないと推定してるんで)
■ このスレッドは過去ログ倉庫に格納されています

ニューススポーツなんでも実況