Компьютер, талантливый трудиться без сбоев, без аварийных остановок, остаётся светло синий мечтой с незапамятных времён. Избавиться от неточностей мы в далеком прошлом не сохраняем надежду: кроме того программы с открытым исходным кодом всё ещё содержат приблизительно одну неточность на каждые две тысячи строчков. В отечественных силах, наверное, только защититься от последствий.
Ещё двадцать лет назад неточность в программе стремилась унести с собой итог работы не только самой программы, но и ОС. Популяризация процессоров, талантливых аппаратно изолировать приложения друг от друга (архитектура x86 может это с середины 80-х), появление массовых операционных совокупностей, могущих применять эту возможность, пара улучшило обстановку. Не стояла на месте и эволюция языков программирования. Вышедший из лабораторий Ericsson чудаковатый Erlang и его последователи делают ставку на конкурентное ответ задачи множеством небольших параллельных процессов: в случае если один из них внезапно «обваливается», соседям это не мешает.
Однако и сейчас ещё стопроцентная надёжность остаётся недостижимой. Кроме того дата-центры таких гигантов бизнеса, как Amazon, Facebook, Гугл, Микрософт, снабжают аптайм только с одной девяткой по окончании запятой (онлайн 99,9 процента времени). Вправе ли мы сохранять надежду, что в один раз обучимся строить счётные автомобили, сохраняющие работоспособность независимо от качества кода, решаемых задач, любых вторых событий? Учёные — пожалуй, единственные, кто ещё не растерял оптимизма. Пару дней назад несколько английских компьютерщиков (University College, London) опубликовала результаты опыта, в рамках которого была создан действующий прототип как раз таковой — полностью надёжной! — автомобили.
Англичане оттолкнулись от несложного рассуждения. Мы строим компьютеры и разрабатываем программы, равняясь на последовательное выполнение команд. Суперскалярные фокусы в процессорах (уже Intel Pentium умел выполнять пара команд в один момент) и суперкомпьютеры с их тысячами параллельно трудящихся узлов только маскируют это препятствие. Посмотрите на картину в целом: целый компьютерный мир всё ещё крутится около идеи последовательного выполнения. В случае если одна команда в потоке ведет к непредвиденному результату, исполнение заканчивается — и вся задача остаётся нерешённой.
Представьте, как смешно смотрелся бы, скажем, человек, надели нас природа таким вычислителем. Мы застывали бы на месте, в случае если под ногой внезапно обнаруживалась бы лужа, теряли дар речи, в случае если «синтезатор голоса» вместо слов внезапно выдавал бы кашель и хрипы. Слава всевышнему (либо эволюции), живые совокупности строятся по иному принципу. В живой природе балом правит децентрализованный, вероятностный, массивно-параллельный подход. Делая собственные повседневные функции, тело приобретает данные из нескольких источников, обрабатывает их независимо и не в унисон, а при непредвиденных обстановок адаптируется, оценивая и корректируя состояние вышедших из строя узлов за счёт узлов, сохранивших работоспособность.
Это и постарались воспроизвести в виде компьютерной архитектуры англичане. Мысль, пара упрощая, следующая: любая громадная задача разбивается на множество свободных кусков, каковые — и это принципиальный момент — вместе с нужными исходными данными передаются на выполнение различным процессорам. Авторы назвали это «системными вычислениями», по причине того, что любой процессор с порученной ему частью задачи тут практически есть самодостаточной совокупностью (архитектура HAoS — Hardware Architecture of Systemic computation). Трудятся они в один момент, асинхронно, как будто бы пчелиный рой либо части людской тела. Вышла из строя одна совокупность? Не беда! Возможно добавить избыточности, сделав резервные совокупности, ожидающие предлога вступить в игру, а возможно вынудить кое-какие из совокупностей смотреть за соседями, скажем, перезагружая их при необходимости. Результатом станет машина, не просто очень устойчивая к сбоям, но и владеющая необыкновенной для компьютеров свойством «лечить» себя на ходу.
Строго говоря, авторы HAoS Америки не открыли, но научная пресса комментирует их работу тепло: англичане спроектировали и выстроили (посредством имеющихся на рынке какое количество и графических процессоров) действующий, фактически применимый образчик сверхнадёжного компьютера с архитектурой, хорошей от главной фон-неймановской, а попутно ещё и доказали, что такая машина возможно производительней, нежели предполагалось ранее.
HAoS — больше, чем легко опыт: уже имеется конкретные замыслы её использования на практике. К сожалению, пока не дома и не в офисе, где цена компьютерного сбоя не так громадна, дабы оправдать смену вычислительной архитектуры. HAoS планируется применить в науке — для действенной симуляции живых совокупностей (наподобие сверхсложных генетических методов либо нейросетей). А следующим кандидатом считаются представители и военные космических отраслей. Так управление дроном думается задачей, прекрасно укладывающейся в возможности и идею HAoS. Равняется и частные космические извозчики наподобие SpaceX смогут заимствовать такую архитектуру для собственных бортовых компьютеров.
Будут ли и персоналки когда-нибудь строиться из системных кубиков а-ля HAoS? Весьма возможно. Но тут нужно сделать приятную поправку: на самом-то деле миллиарды человек уже пользуются преимуществами HAoS-подобных систем. Ежедневно! Чтобы это заметить, нужно перевести внимание с микроуровня на уровень макро. Вспомните о коммерческих дата-центрах, с которых начался сегодняшний рассказ. «Облака», в которых сохраняются эти и выполняются веб-сервисы Гугл, Facebook и других, к настоящему моменту превратились из легко серверных ферм в сложное целое, функционирующее в соответствии с правилами, весьма похожими на живую природу.
Посмотрите, как сооружает собственное облако, скажем, Микрософт. Кирпичиком, небольшой функциональной единицей для неё сейчас стал — как она сама его нарекла — ITPAC: контейнер размером с маленький загородный домик, вмещающий тысячи серверов (на фото выше). Таковой «кирпич» всецело самодостаточен: извне ему требуется лишь какой-никакой широкий интернет и источник электричества-канал, но, строго говоря, кроме того уровень качества этих двух компонент особенной роли не играется. ITPAC бросают в любой точке Почвы — и он вливается в облако, беря на себя часть вычислений. высшая степень и Избыточность абстракции решаемых задач от «железа» разрешают не тревожиться о судьбе конкретного «кирпича»: облако составлено из тысяч аналогичных юнитов — и в случае если какое количество-то из них выйдут из строя, на работоспособности облака в целом это не скажется. Та же картина в Гугл (где сломавшиеся серверы кроме того не трудятся поменять сходу, потому что смысла в таковой спешке нет), в Facebook (где петабайтные кластеры, трудящиеся среди них и под Erlang, обслуживают только пара человек), в Amazon, Dropbox и многих вторых больших компаниях.
Тот факт, что облака иногда всё-таки «зависают», говорит не столько о неспособности инженеров совладать с вечной проблемой, сколько о достигнутом консенсусе между предложением и спросом. Надёжности в 99,9 процента, разумеется, достаточно для рядовых пользователей и бизнеса. А борьба со временем улучшит эту цифру — быть может, и путём заимствования наработок из проекта HAoS. В любом случае, необходимость тревожить рядового пользователя сменой архитектуры покажется вряд ли.