TeCHNoiD

Если вы про износ SSD, то
— в зависимости от поддержки TRIM
а также
— в зависимости от того, сколько у вас RAM
а также
— минимального свободного места, которое будет оставаться на SSD при заполнении виртуальных машин, сохранении их снэпшотов, состояний и т.д. Если останется меньше 30% — то лучше не надо,
а также
— наличия ИБП.

Если RAM мало(4 и меньше), то на SSD лучше разместить своп всей системы, куда кстати будут свопиться и виртуальные машины. Если RAM много (12+), весь кэш в него умещается, и SSD большой — то можете смело размещать на нём часто используемые файлы. Однако, я бы посоветовал такую конфигурацию:
— SSD под систему
— зеркало из двух самсунгов под все ваши проекты и важные данные. здесь же можно виртуальные машины. не страйп, потому что со страйпов очень легко и печально теряется информация.
— третий диск 1,5 ТБ под некритичные данные (бэкапы, дистрибутивы, фильмы-музыка)
Это исходя из того, что винт дешевле купить новый, чем восстанавливать с него информацию у специалистов, а также из того, что винты дохнут внезапно, а также из того, что SSD критично воспринимают сбои питания.

Говоря о self, static и $this, это вопрос не только о статических/нестатических свойствах/методах, но и о Позднем статическом связывании. Поэтому ваше понимание лишь отчасти верное. Думаю, здесь нет смысла пересказывать приведенную документацию, но приведу пример, который, надеюсь, наглядно покажет некоторые различия.

<?php

class A {
	protected int $num;
	
	public function __construct(int $num)
	{
		$this->num = $num;
	}
	
	protected function getNum(): int
	{
		print(__METHOD__ . PHP_EOL);
		return $this->num;
	}
	
	public function getThisNum(): int
	{
		return $this->getNum();
	}
	
	public function getStaticNum(): int
	{
		return static::getNum();
	}
	
	public function getSelfNum(): int
	{
		return self::getNum();
	}
}

class B extends A {
	protected function getNum(): int {
		print(__METHOD__ . PHP_EOL);
		return $this->num + 5;
	}
}

$b = new B(5);
print($b->getThisNum() . PHP_EOL);
print($b->getStaticNum() . PHP_EOL);
print($b->getSelfNum() . PHP_EOL);

B::getNum
10
B::getNum
10
A::getNum
5

Поясню вкратце. Метод `getNum` определен в базовом классе A, но переопределено в классе B. При этом мы дальше создаем экземпляр класса B и работаем уже "через" него. Но все используемые нами методы определены только в классе A и унаследованы в B. Происходит тут примерно следующее:

1. 
   $this - это ссылка на текущий объект (экземпляр класса B), но в области видимости A. Это тоже не самая тривиальная связка для понимания. Но суть в том, что поскольку нам отсюда виден метод getNum, определенный в классе B, будет вызван он. Если метод getNum был бы приватным, то его "версия" в B была бы не видна, и вызвался бы этот метод из A. Ниже приведу еще дополнительные примеры по поводу этого.
   
   
2. 
   Вызывается static::getNum. В данном случае мы "принудительно" вызываем метод того класса, экземпляром которого мы сейчас являемся, то есть B. Если бы метод getNum был приватным, здесь была бы ошибка, поскольку пытаемся дернуть метод, недоступный нам по области видимости.
   
   
3. 
   Вызывается self::getNum. В данном случае мы вызываем метод именно того класса, в котором находимся, то есть A, несмотря на то, что работаем по факту с экземпляром B.
   
   

Говоря об областях видимости, полезно будет также разобраться с замыканиями (Closure), а еще лучше - непосредственно поиграться с ними. Или если быть точнее, с привязкой их (bind) к разным объектам.

Для примера можно взглянуть на этот код

<?php

class A {
	private $num = 1;
}

class B extends A {
	private $num = 2;
}

$closure = function() {
	return $this->num;
};

$closureAA = $closure->bindTo(new A(), 'A');
$closureAB = $closure->bindTo(new A(), 'B');
$closureBA = $closure->bindTo(new B(), 'A');
$closureBB = $closure->bindTo(new B(), 'B');

print($closureAA() . PHP_EOL);
// будет ошибка, поскольку из B пытаемся получить приватное поле A
// print($closureAB() . PHP_EOL);
print($closureBA() . PHP_EOL);
print($closureBB() . PHP_EOL);

1
1
2

В один прекрасный момент, все приходят к одному - что все эти панели чепуха и без них жить значительно проще и легче. Особенно, после того, как растут ваши компетенции, смотрите на конфиги которые создаёт панель и волосы дыбом, после взломов панелей, а это обычно прямой доступ к серверу и прочие приключения. Не говоря уже про лишнее потребление ресурсов сервера. На крайний случай, лучше уж свою накидать какую-то минимальную панель для определённых конкретных задач.

В большинстве случаев, сервер настраивается один раз - дальше всё работает, если что-то нужно обновлять, это можно реализовать скриптами, заодно будет автоматизация. Можно иметь под рукой свои типовые конфиги для различных вещей, вплоть до своего скрипта конфигурации сервера с 0.

Я перепробовал множество панелей, и имел разный опыт эксплуатации и впечатлений оставленных после использования.

Cyberpanel - веб-дизайн панели очень плох, но с точки зрения принципов построения панели для сервера который хостит разные сайты - этой панели нет равных среди всех опробованных мною панелей описанных выше. И open_basedir, и разграничение каждого сайта под отдельным пользователем, и приятная структура хранения сайтов аля: /home/пользователь/public_html,log,backup
И приятные бекапы, и возможность подкрутить всякие штуки по типу Lets Encrypt без проблем, либо ограничение доступа, либо WAF из коробки, либо файловый менеджер, и так далее.

Но за несколько лет меня эта панель достала. Во-первых, она крайне забагована. Её неоднократно ломали, и ломали мои хобби проекты (статичные сайты). Во вторых - у них через версию баги с обновлениями, которые полностью ломают всю панель и возможность входа внутрь. Причем ломается напрочь без возможности починить, только чистая переустановка. Неоднократно сообщал об этом - никакой помощи нет. В третьих - это баги OpenLiteSpeed, либо баги конфигурации веб-сервера. Когда за 1 месяц собирается сессий на 19 гигов в папке lsphp - это вообще не ок, что аж сервер крашит и inodes все заняты. И это один из багов. Были баги с их кешированием которое включено по умолчанию, и приходилось принудительно в каждом .htaccess отключать для доменов. И баги с бекапами были. Т.е. по принципу созданию в абстрактном понимании - панель топ, классная, молодцы, очень хорошо сделано в плане архитектуры. Но вот баги дурацкие, просто выбешивают.
Нравилось с ols что все работало относительно хорошо с любым проектом, любыми реврайтами, кешированиями, разными версиями php, и занимало существенно меньше ресурсов чем апач, либо апач и nginx. Но увы - порекомендовать именно эту панель не могу. Я не знаю что должно произойти что бы её допили до нормального состояния.

VestaCP - долго пользовался этим огрызком. Просто дичайшее отвращение к их темплейтам и конфигам веб-серверов. Какой идиот это писал? И под какие нужды? Огромное количество раз ломали эту панель как в общем, так и лично мне. Но визуально и в плане юзабилити одна из самых беспроблемных и простых и удобных панелей на рынке. В 2021 она мертва. Последние какие-то подвижки и обновления и работа над панелью завершились в году так 2017-2018. Всё остальное делают когда есть свободное время.

HestiaCP - кусок г. базирующийся на VestaCP, после того как последние забили на разработку.
Автор этой панели не вытягивает количество проблем и багов в этой панеле и сообщество. Не компетентен, плохо тестирует. Но с точки зрения безопасности в плане админки - он хорошо поработал. Всё остальное - очень плохо. Может даже инсталятор не установить с первого раза панель. Не полноценно поддерживаются разные конфиги установки без апача например на nginx+php-fpm. Крайне убогие наследуемые шаблоны от весты со всеми косяками и проблемами.
Регулярные баги и проблемы с LetsEncrypt. Жрёт очень много озу. Но визуально хорошо сделано в плане внешнего вида. Под капотом - бред и анархия, но есть куда хуже панельки.
Этой панели так же как и cyberpanel не хватает крепкого сообщества и волонтеров по допилу панели до нужной кондиции. Увы - очень сырая. Но критических багов как в CyberPanel среди веб-компонентов не было выявлено. Регулярно нужно что-то допиливать в панели.

FastPanel - лично для меня это какое-то недоразумение. Снова принципы и архитектура вроде хорошая, но все как-то сыро, и иннертно.

DirectAdmin - скорее мертв, чем жив. Хоть и используется массово на хостерах, но с безопасностью у этой панели швах полный. Если речь идет о шаред хостинге, то взлом одного сайта почти с 100% вероятностью повлечет за собой взлом всех сайтов, так как никаких ограничений в рамках одного аккаунта в плане ACL (разного рода) у панели нет. Из коробки куча абсурда и дегенеративных решений аля блок mysql порта, либо блок других портов через csf. Либо лимиты на размеров файлов. Ранее года 2-3 назад панель была полным днищем. Но после изменений ценовой политики cPanel - нарастили базу, и приняли пулреквесты и предложения, что бы как-то перехватить поток пользователей которые начали мигрировать на другие панели. Я не могу сказать что DirectAdmin в моем личном опыте эксплуатации была хорошей панелью. Мне не понравился опыт взаимодействия, и озвученные выше проблемы особенно с php. В 2021 году интерфейс панели и фичи панели наконец-то удобно расположили, и улучшили для удобства пользователей. Но я бы на этой панеле не сидел. Ну не нравится мне такой подход к панелям в плане архитектуры. Я считаю его не безопасным, убогим.

ispconfig - тяжеловесный монстр со скрытыми платежами аля: "купить нашу документацию, что бы нормально все настроить, иначе из коробки будут неприятные проблемы с производительностью сервера". Пользовался - не зашло вообще ниразу. Не плохая, особых багов не было замечено, но тяжеловесная панель.

centminmod - это даже не панель, это скрипты, и автор eva2000 - очень хорошо поработал над ними, и конфигами nginx, myslq, php, и так далее. Это пример того, как должно быть в любой панели из коробки. Конфиги хорошо отточены, допилены, протестированы, и разраб испытывает страсть к серверам и своей панельке, но у него не хватает скилов создать веб-панельку, которой ой как не хватает этому проекту. Одна из лучших панелей в плане стабильности работы и конфигов серверов, из списка озвученного выше. Но не удобная в использовании. Но конфиги - прям конфетка. Но не для мультисайта вообще ниразу, хоть и опции есть. Эта панель для меня некий фундамент, который до меня настроили хорошо, и дали на эксплуатацию. Ручками придется поработать немного в зависимости от веб-приложения (если специфичное), но не так много как в весте. Обычно пару строк измененний в конфигах, не более. Но не работает нормально с множеством сайтов на одном сервере.

CentOS Web Panel - я вообще не понял что это такое, и зачем оно нужно, и почему оно имеет какую-то популярность.

Froxlor - не продолжительно использовал, неплохо. Какие-то базовые принципы работы с веб-серверов с множеством сайтов соблюдены. Но есть история о ранних взломах этой панели. Поэтому к сожалению этот факт отягощал и заставил метнуться на другую панель. Ничего особенного, но легковесная, простая панелька. Но доверия чуть больше, чем к vestaCP.

Остальные не опубликованные панели так же использовал, но не продолжительно.
Поэтому лень писать о них, и не помню недочеты.

Одна из самых удобных для меня и простых панелей были: cPanel, Plesk, ISPManager но все платные, и дорогие.
Сейчас сижу на самописных скриптах и своих nginx конфигах. Ибо достало каждую панель ручками допиливать, либо получать уведомления что сайт не работает, потому что баг в модуле очередной панели.

И да, в моем "ответе" опыт с 2012 по 2021 год.
И все панели выше я проверял в 2021 году так же, и у кого-то были существенные изменения, а у кого-то вообще их нет. Т.е. отзыв актуален, но субъективен. Возможно у кого-то был другой опыт, но мой таков, каков он есть.