LineHost

Если датацентр принудительно заблокировал IP ручным способом, ответьте на тикет об абузе, что всё почистили, устранили, дальше такого не будет. Само собой извинитесь за задержку, на эти тикеты отвечают люди, иногда действительно усталые.

Если это блокировка автомата, то просто зайдите на свой OVH Manager, откройте список IP и банально снимите блокировку с этого IP...

И что тут удивительного? По крайней мере меня не один раз клиенты просили активировать акаунт без MysQL, но чтоб цена ниже была. Ходят слухи, что мол без MySQL HTML якобы не грузит сервер ;) Есть версии форумов, CMS и других решений на чистом хтмл...

Это цифры со стандартно нагруженных моих нод. Я больше не нагружаю. Нет никакого секрета, SSD я нагружаю только на 1%, в таком режиме сохраняется все достоинства. Вы же скажете, что это безумие. Именно поэтому мои цены чуть выше рыночных цен. И я могу обеспечить параметры ещё выше, но только на тарифах PRO и это только потому, что я псих одиночка, себестоимость моей раб силы самая низкая на рынке для владельца - работаю даром, и могу заметить по крайней мере три человека не считая себя 🤪 Это превосходит то, что Вы можете дать на чудесном облаке. Чудес не бывает, если получаешь удобство, то повышается цена и снижается производительность. Я могу администрировать свои сервера и не совсем удобно ;) И я не один такой, но только вот мы все подходим под одну гребенку, рынок мерит ценой за гигабайт и ядро.

Теперь только не думайте, что я стараюсь обгадить Ваше облако. Ни в коем случае, но Вы перестаньте один раз гнать на одиночные сервера, так как не все безбожно оверселит. Облако надо оверселить сильней, так как оно дорогое удовольствие, упираемся в оптику, 10 GBPs порт и так далее, это дорогие вещи. Я же сразу сказал, что у нас с вами совсем другие сегменты....

Да я и сам отключу сервер, если будет умышленное нарушение. Если взлом, это другой вопрос. По этой причине я теперь продаю только администрируемые выделенные сервера. За десять лет работы было слишком много приключений, поэтому хочется жить спокойно. А с OVH я от 2009 года, так что ситуацию знаю, литовский филиал мою политику тоже знает...

P.S.

К стати, OVH планирует в ближайшее время опять объединить все линейки серверов в один manager.

Андрей, скажу честно - за всю свою практику я не столкнулся с ситуацией, чтобы не хватило моих обычных впсок 😕 С мощных серверов снимал разные проекты, и они продолжали у меня стабильно работать на моих VPS. Просто есть ошибки, которые делают многие вебмастеры, и эти ошибки обязательно надо устранить. Наверно 90% ресурсов, для которых вебмастеры арендуют мощные сервера, может работать на виртуалке с 2-4 GB RAM. Я даже тарифов не делаю по мощнее, так как они реально ненужны. Но обещаю, если столкнусь, когда мне будет недостаточно мощности одного сервера, я обязательно попробую ваш вариант. Вы наверно просто направляете свои услуги на другой сегмент, я нацелен на монстров.

Что касается тестов, не знаю как LW и как на сегодняшний день в OVH, но у меня на впсках с SSD результат зависит от ноды... Но по моему быстрее чем на локальном подсоединении диск, ни одно удаленное хранилище работать не может....

На VPS с одной ноды:

[root@gama /]# date

Fri Nov 11 17:53:20 EET 2016

[root@gama tmp]# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randwrite

test: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64

fio-2.2.8

Starting 1 process

Jobs: 1 (f=1): [w(1)] [100.0% done] [0KB/503.3MB/0KB /s] [0/129K/0 iops] [eta 00m:00s]

test: (groupid=0, jobs=1): err= 0: pid=21717: Fri Nov 11 17:47:59 2016

write: io=4096.0MB, bw=399458KB/s, iops=99864, runt= 10500msec

cpu : usr=10.12%, sys=81.84%, ctx=5277, majf=1, minf=24

IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%

submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%

complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%

issued : total=r=0/w=1048576/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0

latency : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):

WRITE: io=4096.0MB, aggrb=399457KB/s, minb=399457KB/s, maxb=399457KB/s, mint=10500msec, maxt=10500msec

И на root@sigma:/tmp# date

Pn Lap 11 17:54:55 EET 2016

root@sigma:/tmp# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randwrite

test: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=64

2.0.8

Starting 1 process

Jobs: 1 (f=1): [w] [100.0% done] [0K/267.1M /s] [0 /68.6K iops] [eta 00m:00s]

test: (groupid=0, jobs=1): err= 0: pid=29252

write: io=4096.0MB, bw=267545KB/s, iops=66886 , runt= 15677msec

cpu : usr=5.28%, sys=43.22%, ctx=3407, majf=0, minf=17

IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%

submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%

complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%

issued : total=r=0/w=1048576/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):

WRITE: io=4096.0MB, aggrb=267545KB/s, minb=267545KB/s, maxb=267545KB/s, mint=15677msec, maxt=15677msec

И на VPS на ноде с меньшей нагрузкой:

root@sigma:/tmp# date

Pn Lap 11 17:54:55 EET 2016

root@sigma:/tmp# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randwrite

test: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=64

2.0.8

Starting 1 process

Jobs: 1 (f=1): [w] [100.0% done] [0K/267.1M /s] [0 /68.6K iops] [eta 00m:00s]

test: (groupid=0, jobs=1): err= 0: pid=29252

write: io=4096.0MB, bw=267545KB/s, iops=66886 , runt= 15677msec

cpu : usr=5.28%, sys=43.22%, ctx=3407, majf=0, minf=17

IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%

submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%

complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%

issued : total=r=0/w=1048576/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):

WRITE: io=4096.0MB, aggrb=267545KB/s, minb=267545KB/s, maxb=267545KB/s, mint=15677msec, maxt=15677msec

Обе ноды уже укомплективанны... Чтоб не было разных мыслей, прилагаю картинку.

Если у меня будет больше клиентов на PRO уровне услуг, я могу обеспечить этот параметр примерно на 50% лучше.

Ниже результат с KVM виртуалки, которая сама по себе уже во время тестирования имела load avg ~1.86

[root@serv tmp]# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randwrite

test: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64

fio-2.0.13

Starting 1 process

test: Laying out IO file(s) (1 file(s) / 4096MB)

Jobs: 1 (f=1): [w] [100.0% done] [0K/154.8M/0K /s] [0 /39.7K/0 iops] [eta 00m:00s]

test: (groupid=0, jobs=1): err= 0: pid=23908: Fri Nov 11 18:59:49 2016

write: io=4096.0MB, bw=179866KB/s, iops=44966 , runt= 23319msec

cpu : usr=13.94%, sys=59.07%, ctx=24611, majf=1, minf=18

IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%

submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%

complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%

issued : total=r=0/w=1048576/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):

WRITE: io=4096.0MB, aggrb=179866KB/s, minb=179866KB/s, maxb=179866KB/s, mint=23319msec, maxt=23319msec

Disk stats (read/write):

vda: ios=998/1043131, merge=11/401, ticks=4493/749421, in_queue=753773, util=100.00%

Да всё нормально в OVH, были проблемы административного характера несколько лет тому назад, теперь теперь ситуация утреслась. Техническая поддержка специфическая, но в общем на равне с другими аналогичными датацентрами.

Если не требуется администрирование, то само собой нет смысла через реселера брать. Но если администрирование на стороне, то через реселера реально выгодней, так как всё в одних руках и решается быстрей. Цена фактически не отличается. К примеру я для основной OVH линейки даю доступ к нативной OVH панели.

Сервер в сети, поддержка работает. ТС более менее ситуцию разьяснил, просто надо решать проблемы и не откладывать...

Уточняем, при чем тут я и какая то статья? :)

1, 2 не имею ничего общего с этим

Не пугайте, плавали, ploop ничего не мeняет, это же имидж или раздел на удаленном хранилище на общей файловой системе. Ploop я использовал лет пять тому назад с OpenVZ, подключал дополнительно виртуалкам раздел под MySQL внутри виртуалки. Не оправдался, лучще simfs на том же SSD. Если уж говорить о производительности, то надо говорить или о прямом подключении LVM или iSCSI или о ещё какой то хитрой системе. И самое главное, о канале между вычислительным центром и хранилищем, тут слабое место.

Скажем тут наши мнения расходятся на 180 градусов, не думаю что стоит ввязыватся в спор. Цена/качество для клиента лучше будет на стороне моего понятия. Удобство для хозяйна, да на Вашей стороне.

50 Ghz суммируя потоки? Сами понимаете, что 50 Ghz тут даже не пахнет, даже при одном клиенте на всём облаке. Прикинем сколько будет клиентов, которые все будет шарить эти потоки ;) Я противник суммировать частоту процессора, это технически неграмотно. Если аппликация может использовать несколько потоков, то все потоки будут обрабатываться на частоте ядра, с тем приоритетом, который выставлен для контейнера, только в несколько потоков. Если аппликация не способна работать с несколькими потоками, то частота будет та же, только всего один поток. И эти другие vCPU просто будет простаивать. Это же сами понимаете, но всё равно занимаетесь маркетингом ;)

Также повторюсь, что не имею никакого отношения к каким то статьям, также почти всё своё время работы в этой области предлагал OpenVZ + один из Xen/Vmware/KVM. Virtuozzo тоже только уважаю, но не вижу смысла использовать, не нравится мне платные имитации виртуализации. Если для каких то проектов пойти на платную платформу, то только на базе Citrixx или Vmware.

Всё там должно уладится. Ответил.

---------- Добавлено 10.11.2016 в 16:14 ----------

А где всё выполняется 100% по SLA? Я по крайней мере не знаю такой конторы.

Den73, всё зависит от линейки и самой проблемы. Кое что они меняют без спроса, даже проблема отозвать замену. Просто надо знать систему, привыкнуть и иметь план Б.