^Up^

█║ S Y N C H R O K N O T ║█






█║▌║▌║ SynchroKnot Instructional Manual ║█

█║▌║ SynchroKnot software works with any AMD64 [x86_64] hardware.
█║▌║ SynchroKnot software installs on Debian 9 / 10 [kernels 4.9 | 4.19].
█║▌║ SynchroKnot software also installs on any Debian derivative with kernels 4.9 | 4.19 that accept external non-signed kernel modules.
**This document is a work-in-progress and may contain errors. Content can be added/modified anytime.** *Power Modules may have their own separate manuals. *Basic knowledge of ZFS on Linux filesystem is required. *ARM64 [aarch64] licenses may be released in the near future. *Please read and understand the SynchroKnot License under the "About" section of the SynchroKnot official website. *Take your time to understand for a fun learning curve. Good Luck! and ^Zip+++Up^ your Spacesuits!!

║█║ Index of Shortcuts:

║█║ Install the required packages with APT ║█║ Spatial Fabric Satellite - 1-Step Deployment ║█║ Spatial Fabric Array ║█║ Spatial Cluster ║█║ Microcosm, Macrocosm, Intercosm ║█║ Excerpts ║█║ Shoutout ║█║ Distance Vector ║█║ Inbound & Outbound Traffic Overview To & From Spatial Fabric Satellites to help set up & configure your own switch/router ║█║ Gateway for Customer / Tenant Inbound and Outbound Traffic to and from the Spatial Fabric Satellite(s) ║█║ Layer 2 Peer-to-Peer VPN ║█║ Spatial Fabric Satellite Interconnection Across Multiple Sites By The Infrastructure Provider ║█║ Spaceway : Power Module ║█║ Spatial Fabric Traverser with Intersecter : Power Module
║█║ Infrastructure Engine ║█║ Spacesuit ║█║ Spatial Virtual Machine ║█║ Disperser ║█║ Synchroknot [User] ║█║ Synchroknot Decentralized Access Control Identification - SDAC and VM-SDAC ║█║ Spatial Fabric Array Information, List and Log Panorama ║█║ Stagnant Virtual Machine ║█║ Zombie Virtual Machine ║█║ Relocate Virtual Machine ║█║║║ Modify Virtual Machine ║█║║║ Network Operations ║█║ SpaceBuoy ║█║ DHCPCAST ║█║ Flood Control ║║█║║║ Storage Operations ║█║ Storage Datapath Access ║█║║║ Spatial Fabric Satellite : Deployment Options ║█║║║ Built-in Automatic Switch with SATELLITE TREE PROTOCOL ║█║║║ SynchroKnot Auto NAT Enablement
║█║ IMPORTANT REQUIREMENTS FOR PERFORMANCE AND SCALABILITY:
*** You can use any AMD64 [x86_64] hardware with LOCAL DRIVES ONLY. *** *** DO NOT import block devices via iSCSI, SAN, NAS, Distributed block/file storage or other methods. *** *** DO NOT use Blade Servers. *** *** DO NOT run SynchroKnot Software in virtual machines. *** *** Use Regular, Inexpensive and High-Performance Commodity Hardware [Eg. embedded/workstation/desktop motherboards with AMD [Embedded Ryzen/EPYC | Ryzen] / INTEL [i7/9 etc]. *** *** Read "GENERIC GUIDE TO HARDWARE SELECTION, CONSULTING AND PRICING" on the website for more information. ***
║█║ Install the required packages with APT:
apt-get -y install uml-utilities numactl bridge-utils vlan apache2 qemu-kvm socat ebtables ethtool iptables inotify-tools curl tcpdump dnsmasq lsof ldap-utils nodejs net-tools rsync *** Only proceed to the next step if the all packages have been successfully installed *** ■ If you happen to need a graphical user interface. This is not a requirement but may be helpful. apt-get install x-window-system-core gdm3 firefox synaptic ■ The known-to-be-working version of bitcoind comes packaged with the SynchroKnot software. Feel free to download and verify the checksum of the latest version from the official Bitcoin site.
█ Install and set up ZFS on Linux with a volume of choice with the name tier0 and mounted at /tier0
■ Open /etc/apt/sources.list and check if "contrib non-free" is added after main, if not do: sed -i 's/main/main contrib non-free/g' /etc/apt/sources.list ■ Make sure the repo is pointing correctly and the local cdrom/dvd option if any is commented. apt-get update ##For most Debian flavors Linux headers must be installed for zfs apt -y install linux-headers-$(uname -r) apt -y install zfs-dkms Create a zfs volume of your choice with the name tier0. eg. zpool create tier0 /dev/sdb by default mounts at /tier0. ■ If you don't have an extra disk or partition then you can create a file-based ZFS volume: modprobe zfs mkdir /root/zfs truncate -s 4000M /root/zfs/zfs0 zpool create tier0 /root/zfs/zfs0 zpool scrub tier0 zpool status ■ In some situations, after a reboot you may have to do : zpool import tier0 OR losetup /dev/loop0 /root/zfs/zfs0 && zpool import tier0 █ IMPORTANT: ■ *** The ZFS tier0 volume *MUST* always be up [online] and mounted at /tier0 before proceeding with any SynchroKnot operation *** ■ *** Confirm the workability and testing of the network, for example, checking if your Ethernet cards [drivers and cabling] are set up and working individually and also when connected in ring or torus topology. Verify if VLANs [single, double and triple stacks] work when set up [ie 802.1ad+802.1q+802.1q]. This is a requirement every time an operating system is updated/upgraded.*** ■ *** Be sure to follow only the QEMU-KVM manual [not libvirt] for syntaxes/options regarding the virtual machine. Wrong options and/or syntaxes may not start/function the virtual machine as expected. When in doubt start a virtual machine using the QEMU-KVM syntax/option[s] from the commandline and then incorporate them into the Spacesuit of the virtual machine using the trigger vm-modify. *** If USB Ethernet adapters are used for testing or for whatever reason, then Linksys 3.0 Gigabit Ethernet Adapter [Model No. USB3GIGV1] is known to work [Eg. It does not have to be unplugged and plugged back in while testing bringing down and up ethernet interfaces].
║█║ Spatial Fabric Satellite - 1-Step Deployment:
█ Deploy Synchroknot software :
***IMPORTANT: Always login/logout as a non-root user with SSH [remotely/locally if logged in with GUI/Shell], and then become root and perform the operations below.*** Please ***DO NOT*** login with GUI/Non-GUI directly to perform the operations below or else when you logout the SynchroKnot and other daemons/processes started will be stopped by the operating system. [screen, nohup and other tools & their combination have been tried but it does not seem to resolve this quirk].
a] Install SynchroKnot-Base - This is a one-time operation.
Place all the SynchroKnot tar files and SynchroKnot-Base.sknt in a new directory in : /root/synchroknot-latest Then, as the root user do : cd /root/synchroknot-latest && chmod 755 SynchroKnot-Base.sknt && ./SynchroKnot-Base.sknt
b] Place the synchroknot.license and other Power Module license[s] [eg. level2-security-power-module.license] in:
/tier0/synchroknot/www/synchroknot-modules and do: chown www-data:www-data *.license && chmod 440 *.license ***IMPORTANT: you will see a message depicted below in Log Panorama if the license is not placed appropriately or if a copy of the license is detected across Spatial Fabric Satellites. All SynchroKnot management operations will be halted. The remedy is to have the license in place with the correct permissions as shown above: ..... 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z @ 28.9.0.1 : Illegal License Detected - All Timers Will Be Out Of Sync! : Remove All Illegal Licenses. Example of contents in /tier0/synchroknot/www │ ├── css/ ├── js/ ├── SynchroKnot-Datadecenter-Fabric.sknt ├── SynchroKnot-Identify.sknt ├── synchroknot-modules/ ├── SynchroKnot.sknt ├── tightvnc-jviewer.jar ├── webview.sknt Example of contents in /tier0/synchroknot/www/synchroknot-modules │ ├── disperser-enable.sknt ├── space-debris.sknt ├── spatial-cluster-ctl.sknt ├── synchroknot.license ├── spatial-fabric-satellite-ctl.sknt ├── vm-create.sknt ├── vm-delete.sknt ├── vm-modify.sknt ├── vm-relocate.sknt ├── vm-start.sknt *** Note: The size of largest file is only about 258K! *** *** Simply replace the files to update to a newer version of SynchroKnot without disrupting/stopping any Spatial Cluster[s], Virtual Machines, Remote Consoles, Storage Data Transfers and other aspects! ***
c] Set up Spatial Fabric Satellite :
echo "trigger:setup ip:28.9.0.1 ports:eth0,eth1" | /tier0/synchroknot/www/synchroknot-modules/spatial-fabric-satellite-ctl.sknt ***Important: To modify the setup, do a reboot of the Spatial Fabric Satellite and redo the above command with the changes.*** Note: trigger:setup-rt will be released shortly which will allow the non-disruptive modification even if the spatial clusters are active! ■ Use an IP address only in the 28.0.0.0/7 network. ■ The SynchroKnot Infrastructure Engine Web Interface access will always be in the 10.0.0.0/7 network corresponding to the IP set in the 28.0.0.0/7 network. Tenant access to this IP address can be given via the internal network or via VPN. Example : If the IP address set above is ip:28.9.0.1 the SynchroKnot Infrastructure Engine Web Interface access IP will be 10.9.0.1. General details of the 28.0.0.0/7 network: IP Address: 28.0.0.0 Network Address: 28.0.0.0 CIDR Notation: /7 Usable Host IP Range: 28.0.0.1 - 29.255.255.254 Broadcast Address: 29.255.255.255 Total Number of Hosts: 33,554,432 Number of Usable Hosts: 33,554,430 Subnet Mask: 254.0.0.0
d] Invoke Spatial Fabric Satellite - Invocation is necessary after the Spatial Fabric Satellite starts [boots] successfully :
echo "trigger:invoke" | /tier0/synchroknot/www/synchroknot-modules/spatial-fabric-satellite-ctl.sknt Example output: echo "trigger:invoke" | /tier0/synchroknot/www/synchroknot-modules/spatial-fabric-satellite-ctl.sknt SynchroKnot : Invoking ... Inserting Satellite Tree Protocol Module : Success Enabling Satellite Tree Protocol : Success Starting Blockchain Gateway : Success Starting Webserver : Success Starting Storage Datapath Access Root : Success Starting SynchroKnot Gateway : Success Starting SynchroKnot Secure Gateway : Success Starting Transmigrate for Spatial Fabric Array : Success Starting Transmigrate for Spatial Fabric Satellite : Success SynchroKnot : Success : Done and Invoked.
║█║ Spatial Fabric Satellite : Post Setup/Modify
STEP 1 : Make sure that the ZFS tier0 volume is up [online] and mounted at /tier0 STEP 2 : Make sure that the network cables are in place and then invoke the Spatial Fabric Satellite - Invocation is necessary after the Spatial Fabric Satellite starts [boots] successfully : echo "trigger:invoke" | /tier0/synchroknot/www/synchroknot-modules/spatial-fabric-satellite-ctl.sknt STEP 3 : Proceed as usual with spatial-cluster-ctl.sknt [create, modify, start, force-stop, remove] and other operations as needed.
║█║ Spatial Fabric Satellite : Help and other advanced options
1] trigger:help echo "trigger:help" | /tier0/synchroknot/www/synchroknot-modules/spatial-fabric-satellite-ctl.sknt Example output: █║▌║▌║ <<^>> SynchroKnot License ID : 19vy4inWdEfavwtPWb68GPp7WDihEwJ1Fr │ ├──█║▌ Organization ID : 1Gqb8EPWVCmyKqMJKeso6kFRn1ptsmU2LZ │ ├──█║▌ Organization : example-corp │ ├──█║▌ Country : example-country │ ├──█║▌ Authorized CPUs : 64 │ ├──█║▌ Expiration Date : Sat-Nov-28-17:05:47-CET-2020 │ ├──█║▌ Version : 1.0 │ ├──█║▌ Power Module[s] : arpless-interstellar, authcontrol, blockchain-ssh, fastr, interstellar, level2-security, reachout, realtime-cache, synchrosync │ └──█║▌ SynchroKnot : trigger:[help|invoke|performance|status|service-restart|enable-network-ports|setup] ║▌█ 2] trigger:status Example output: SynchroKnot Secure Gateway : ACTIVE on 127.0.0.1:443 SynchroKnot Gateway : ACTIVE on 127.0.0.1:80 SFA Transmigrate : ACTIVE SFS Transmigrate : ACTIVE SFS Storage Data Path : ACTIVE Blockchain Gateway : ACTIVE SynchroKnot Ethernet Ports : eth0 eth1 3] trigger:enable-network-ports Enables and reinstates all the physical network ports [starting with eth and en] that are assigned to the Spatial Fabric Satellite. [With certain USB Ethernet adapters the network port[s] could go offline when the machine goes into or wakes up from sleep/hibernate mode or when the network interface is manually brought down.] 4] trigger:service-restart Restarts any service that is found inactive. Eg. the Blockchain Gateway is sometimes known to go offline after a system wakes up from hibernate/sleep. 5] trigger:performance Automatically optimizes the Spatial Fabric Satellite for high-performance.
║█║ Spatial Fabric Array :
Bifurcated CPU and Memory resources given to a Customer / Tenant on a particular Spatial Fabric Satellite. The Spatial Fabric Array inherits the IP address of the underlying Spatial Fabric Satellite, and a unique port number is automatically computed from the Blockchain ID of the Tenant. The same port number is automatically computed for the Tenant with the same Blockchain ID across all Spatial Fabric Satellites [locally or globally]. This distinct feature allows the internal control and management traffic [unicast/broadcast/multicast] of the Tenant to be bifurcated and directed to only the Spatial Fabric Satellite(s) where the Tenant Spatial Cluster exists, and *NOT* to all Spatial Fabric Satellite(s) as one large unicast/broadcast/multicast domain for all the Tenants. *Important: When the key and value spatial-fabric-array:{IP address} is used together with any trigger, then ONLY the Spatial Fabric Array with that IP address hears the trigger.*
║█║ Spatial Cluster :
Customer / Tenant setup, modification, network bifurcation and interconnection of Spatial Fabric Arrays across different Spatial Fabric Satellites.
█ Spatial Cluster Create :
Create a Spatial Cluster for the Tenant on single or multiple Spatial Fabric Satellites locally or globally dispersed. The Tenant can access the SynchroKnot Infrastructure Engine Web Interface on any Spatial Fabric Satellite where the Spatial Cluster was created and manage any Spatial Fabric Array with the right credentials. ■ The Tenant gives the Infrastructure Provider their Blockchain ID [i.e Bitcoin Address] and a message signed with their Private Key. The Infrastructure Provider can request the Tenant to sign a specific message to validate authenticity. ■ The Infrastructure Provider verifies the signed message. Successful verification proves the Tenant is the owner of the Private Key and the Infrastructure Provider can go ahead and create the Spatial Cluster. ■ For example, the Tenant can sign a message using bitcoin-cli or bitcoin-qt [GUI] with the command "signmessagewithprivkey", and the Infrastructure Provider can verify it with the command "verifymessage" █ IMPORTANT: ■ Only Bitcoin Address Type Legacy [i.e an address starting with 1] is supported. ■ It is recommended that a Bitcoin Address is generated/verified using the official Bitcoin Core software [available at https://bitcoincore.org]. Example of creating a Spatial Cluster with trigger spatial-cluster-create: echo "synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z interstellar:1000 cpu:0,1,2,3 quota:2G trigger:spatial-cluster-create" | /tier0/synchroknot/www/synchroknot-modules/spatial-cluster-ctl.sknt ■ synchroknot:[Legacy Bitcoin Address of the Customer / Tenant] ■ interstellar:[single OR double OR triple stacked VLAN. Example : 1000 | 1000.1000 | 1000.1000.1000] ■ cpu:[comma separated value of the CPU cores you would like the Customer / Tenant to have] ■ quota:[size in GB. Example : 500G] █ IMPORTANT: ■ It is a requirement that each Spatial Cluster created on Spatial Fabric Satellite[s] with a Bitcoin Address of the Tenant be given a unique interstellar [i.e single OR double OR triple stacked VLAN] per Infrastructure Provider site. In other words, each Tenant *MUST* have a unique VLAN. For example, at the Infrastructure Provider site A, there is a physical cluster of 16 Spatial Fabric Satellites. A Spatial Cluster with the Bitcoin Address 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z is requested to be created on 6 Spatial Fabric Satellites by the Tenant. Then, the Infrastructure Provider first assigns and associates a free interstellar [i.e VLAN 1000 from the example above] to the Tenant Spatial Cluster 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z on site A, and then creates the spatial cluster 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z using "trigger:spatial-cluster-create" across any of the 6 Spatial Fabric Satellites with the requested resources with the *SAME* interstellar 1000. For more information, please read Spatial Fabric Satellite Interconnection Across Multiple Sites By The Infrastructure Provider. █ It is *NOT* necessary to create the same Spatial Cluster on all Spatial Fabric Satellites. All the virtual machines in the spatial cluster will have transparent layer 2 connectivity! Example: If you have 10 Spatial Fabric Satellites, then you can create Spatial Cluster 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z as needed on all 1 to 10 OR 3 and 8 OR 2,3,6,8,9 etc. █ You have the flexibility to transparently expand and contract the spatial cluster as and when you need *WITHOUT* disrupting/interrupting the existing Spatial Clusters, virtual machines and services already present & running across all Spatial Fabric Satellites.
█ Spatial Cluster Start :
The ZFS tier0 volume must be up [online] and mounted at /tier0 ***Important : As mentioned above, always login in as non-root user with SSH [remotely/locally], and then become root and perform the operations below.*** echo "synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z trigger:spatial-cluster-start" | /tier0/synchroknot/www/synchroknot-modules/spatial-cluster-ctl.sknt Example output: echo "synchroknot:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE trigger:spatial-cluster-start" | /tier0/synchroknot/www/synchroknot-modules/spatial-cluster-ctl.sknt SynchroKnot : Starting Spatial Cluster : 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE SynchroKnot : Success : Spatial Cluster 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE Invoked.
█ Spatial Cluster Modify :
trigger:spatial-cluster-modify piped to /tier0/synchroknot/www/synchroknot-modules/spatial-cluster-ctl.sknt with the options below : add-cpu:[physical cpu has to exist and within the allowed limit mentioned in the license] remove-cpu:[cpu number] tier0-quota:[example: 128G] *Important: spatial cluster has to be modified before being started to reflect the changes.*
█ Spatial Cluster Force Stop :
echo "synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z trigger:spatial-cluster-force-stop" | /tier0/synchroknot/www/synchroknot-modules/spatial-cluster-ctl.sknt A complex attempt will be made to stop all aspects of the specific Spatial Cluster! Note: You will need the key and value am-i-sure:yes for trigger spatial-cluster-force-stop to work.
█ Spatial Cluster Blockchain Identification :
Find out how many spatial clusters exist on the Spatial Fabric Satellite echo "synchroknot:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE trigger:scid" | /tier0/synchroknot/www/synchroknot-modules/spatial-cluster-ctl.sknt Example output: echo "synchroknot:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE trigger:scid" | /tier0/synchroknot/www/synchroknot-modules/spatial-cluster-ctl.sknt Spatial Cluster Blockchain Identification ----------------------------------------- 18aMrKwYjRc9T6gMoiPgQS4ggSRZqtV3Au 19cTPsdaoYu8w47yC1hqYJrcBWSvF5eZVB 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z 1JsMy66EGn1Yzw9FS5ky2EnhyUHUVuNrDe 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE
█ Spatial Cluster Status :
Displays Realtime Active/Inactive Status Information [processes/daemons/ports] echo "synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z trigger:spatial-cluster-status" | /tier0/synchroknot/www/synchroknot-modules/spatial-cluster-ctl.sknt Example output: echo "synchroknot:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE trigger:spatial-cluster-status" | /tier0/synchroknot/www/synchroknot-modules/spatial-cluster-ctl.sknt Spatial Cluster : 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE Spatial Cluster ID : 43501 Storage Quota : 8G Spatial Cluster Network : ACTIVE Spatial Cluster Listener : ACTIVE on Port : 43501 Storage Data Path : ACTIVE on Port : 22890 Log Panorama : ACTIVE on Port : 18861 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: SynchroKnot Secure Gateway : ACTIVE on 127.0.0.1:443 SynchroKnot Gateway : ACTIVE on 127.0.0.1:80 SFA Transmigrate : ACTIVE SFS Transmigrate : ACTIVE SFS Storage Data Path : ACTIVE Blockchain Gateway : ACTIVE
█ Spatial Cluster Service Restart :
echo "synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z trigger:spatial-cluster-service-restart" | /tier0/synchroknot/www/synchroknot-modules/spatial-cluster-ctl.sknt This will only restart SynchroKnot processes/services/daemons related to the specific Spatial Cluster without affecting virtual machines, disperser, power modules and other aspects. The SynchroKnot listening processes/services/daemons of the Spatial Cluster whose service is being restarted may be impaired [usually under a second] from hearing during the restart process. If a push/pull-based data transfer was initiated with Storage Datapath, then it might have to be reinitiated.
█ Spatial Cluster Remove :
echo "synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z trigger:spatial-cluster-remove" | /tier0/synchroknot/www/synchroknot-modules/spatial-cluster-ctl.sknt Note: You will need the key and value am-i-sure:yes for trigger spatial-cluster-force-remove to work.
█ Spatial Cluster CPU Map : Displays CPU to Spatial Cluster Mapping
Displays the mapping betwwen the CPU cores on the system to the Spatial Cluster. echo "trigger:cpu-map" | /tier0/synchroknot/www/synchroknot-modules/spatial-cluster-ctl.sknt You will notice in the example below that only one or two cpu cores are dedicated to a Spatial Cluster. This was done only for testing purposes to check and push the limits. It should not be done in actual use case scenarios. You should dedicate 4 or more cores per Spatial Cluster depending on the number of virtual machines and their type of workload. Example output: echo "trigger:cpu-map" | /tier0/synchroknot/www/synchroknot-modules/spatial-cluster-ctl.sknt Total CPUs : 0 - 3 CPUs : Spatial Cluster ---- : --------------- CPU 0 : 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE CPU 1 : 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE CPU 2 : 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z CPU 3 : -
█ Spatial Cluster Interstellar Map : Displays Single/Double/Triple Stacked VLANS to Spatial Cluster Mapping
echo "trigger:interstellar-map" | /tier0/synchroknot/www/synchroknot-modules/spatial-cluster-ctl.sknt Example output: echo "trigger:interstellar-map" | /tier0/synchroknot/www/synchroknot-modules/spatial-cluster-ctl.sknt Spatial Cluster : Single/Double/Triple Stacked VLANs --------------- : ---------------------------------- 18aMrKwYjRc9T6gMoiPgQS4ggSRZqtV3Au : 1000 19cTPsdaoYu8w47yC1hqYJrcBWSvF5eZVB : 1000.1000 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z : 10.100.1000 1JsMy66EGn1Yzw9FS5ky2EnhyUHUVuNrDe : 1000.1000.1000 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE : 9
█ Spatial Cluster Help : Displays Information about License and Triggers
echo "trigger:help" | /tier0/synchroknot/www/synchroknot-modules/spatial-cluster-ctl.sknt Example output: echo "trigger:help" | /tier0/synchroknot/www/synchroknot-modules/spatial-cluster-ctl.sknt █║▌║▌║ <<^>> SynchroKnot License ID : 19vy4inWdEfavwtPWb68GPp7WDihEwJ1Fr │ ├──█║▌ Organization ID : 1Gqb8EPWVCmyKqMJKeso6kFRn1ptsmU2LZ │ ├──█║▌ Organization : example-corp │ ├──█║▌ Country : example-country │ ├──█║▌ Authorized CPUs : 64 │ ├──█║▌ Expiration Date : Sat-Nov-28-17:05:47-CET-2020 │ ├──█║▌ Version : 1.0 │ ├──█║▌ Power Module[s] : arpless-interstellar, authcontrol, blockchain-ssh, fastr, interstellar, level2-security, reachout, realtime-cache, synchrosync │ └──█║▌ SynchroKnot : trigger:[help|cpu-map|interstellar-map|scid|cpu-lock-map|cpu-unlock|cpu-lock] ▌ trigger:spatial-cluster-[status | create | modify | start | service-restart | force-stop | remove] ║▌█
║█║ Microcosm, Macrocosm, Intercosm :
■ Microcosm, Macrocosm and Intercosm can be set and updated by the Tenant after the Spatial Fabric Array is created by the infrastructure provider. ■ Every Tenant on the hardware can set up their own Microcosm, Macrocosm and Intercosm. Microcosm : tag(s) [up to 15 csv] related to where the Spatial Fabric Array is located [eg. city/town, zip code, street etc]. Macrocosm : tag(s) [up to 15 csv] related to region where the Spatial Fabric Array is located [continent, country, state etc]. Intercosm : tag(s) [up to 15 csv] related to row, stack/rack/shelf, CPU type, network type, topology group/team/provider identification or Blockchain ID for correspondence, management and support. trigger:spatial-fabric-array-modify spatial-fabric-array:[ip address] intercosm:[tag(s) up to 15 csv] macrocosm:[tag(s) up to 15 csv] microcosm:[tag(s) up to 15 csv] [See usage examples under Excerpts.]
║█║ Excerpts :
Excerpts are various informational & identification tags given to virtual machines for their decentralized search and management. Excerpts can be set and modified with the trigger:vm-modify with up to 15 comma-separated values having the legal characters: 0-9 a-z , - The most powerful, fine-grained search specificity and functionality is invoked with the built-in Parallel Regex Logic & Engine when excerpts are further used in combination with Microcosm, Macrocosm and Intercosm. Even more powerful, regional search specificity can be achieved by using a network mask with sub-trigger mask: *** Assign IP addresses to Spatial Fabric Satellites intelligently so as to take full advantage of the mask: functionality across regions with or without the use of Microcosm, Macrocosm and Intercosm for near-endless, fine-grained search & management possibilities! ***
Setting Excerpts to a Virtual Machine:
trigger:vm-modify spatial-fabric-array:[ip address] synchroknot:[vm name] excerpts:[up to 15 separated by commas] Excerpts may encompass [operating system name eg. linux|freebsd|solaris etc],[application type eg. webserver|database etc],[application name eg. apache|mysql etc],[department/group type/id eg. devteam101,applications etc],[mac address[es] of the virtual machine without the colon (:)],[IP addresses replacing the . with -] Examples of setting Excerpts [all must be in lower case]: linux,webserver,apache,devteam101,dac000143799,192-168-1-21 freebsd,database,mysql,dbateam1,dac000143885,10-10-11-110 * MAC address[es] can be very helpful in finding out the virtual machine name, location etc. As some some network application log files may only have MAC address[es], you might want to ascertain which virtual machine is associated with that particular MAC address[es]. This functionality is quite unique, as finding a virtual machine from its MAC address is not possible/not as simple with most modern virtualization systems in centralized or distributed/decentralized setups. * ■ Excerpts are inherited by the virtual machines when created from a parent Spacesuit or a virtual machine. So, if a MAC address and/or IP address has been added to the excerpts, the excerpts will need to be updated with new MAC/IP address[es] or removed as needed. ■ The Spacesuits must not have MAC addresses OR IP Addresses added to their Excerpts. The different SynchroKnot Excerpts triggers utilizing different transports automatically give exceptional control, reach and responsiveness over decentralized virtual infrastructure. There are many variants of Excerpts: 1] Excerpts - are specialized for EXACT matches and are invoked with trigger:excerpts - works with mask: 2] Excerpts Regex - are specialized for multi-function REGEX with multiple OR, AND and NOT matches, and are invoked with trigger:excerpts-regex. This is the default. Works with mask: 3] Excerpts Realtime Cache - are part of Realtime Cache Power Module that are specialized for EXACT matches with instantaneous real-time response, and are invoked with trigger:excerpts-rtc 4] Excerpts Realtime Cache Regex - are part of Realtime Cache Power Module that are specialized for multi-function REGEX with multiple OR, AND and NOT matches with instantaneous real-time response, and are invoked with trigger:excerpts-rtc-regex 5] Excerpts and Excerpts Regex are also fully integrated with the Reachout Power Module utilizing reliable transport [ TCP ] to perform Decentralized Realtime Precision Parallel Search. *** All frequently used or long/complex Excerpts Regex & Excerpts Realtime Cache searches can be converted into presets called Shoutouts so that the results can be realized with just a click of a button - see the next Shoutout section *** - Up to 15 tags [csv] can be searched for exact match with trigger:excerpts. - With trigger:excerpts and trigger:excerpts-rtc, when a comma is used as a separator SynchroKnot understands it as looking for multiple exact matches. - With trigger:excerpts-regex and trigger:excerpts-rtc-regex, when a comma is used as a separator SynchroKnot understands it as an AND operator. There can be only one AND operator [i.e ,]. - Clicking on "SYNCHROKNOT" on the Infrastructure Engine or leaving a blank value for the key synchroknot: matches all authorized virtual machines and returns their real-time status and metadata [visible via mouse-over]. - Refer to video demonstration for an outdated yet basic example.
Operators for trigger:excerpts-regex and trigger:excerpts-rtc-regex:
Comma [,] - , is an AND operator. Eg. tag1,tag2 - There can be only one AND operator [in the near future up to 5 will be supported]. Pipe [|] - | is an OR operator. Eg. tag1|tag2 OR (tag1|tag2) Greater than and Less than [< >] - < > is a NOT [Other Than] operator. Eg. <tag1>,tag2 - Only work with Microcosm, Macrocosm and Intercosm. Dot Star [.*] - .* is an Expansion operator. Eg. l.*ux Minus [-] - - is a Range operator. Eg. 0-9a-z ■ Below are simple examples to get started with excerpts-regex. Replace trigger:excerpts-regex with trigger:excerpts-rtc-regex if the Realtime Cache Power Module is enabled. [This section will be updated with moderate-to-complex examples in the near future.] trigger:excerpts-regex intercosm: macrocosm: microcosm: d-vector: synchroknot:webserver - returns: webserver
Examples with Range and OR operators:
trigger:excerpts-regex intercosm: macrocosm: microcosm: d-vector: mask: synchroknot:webserver|linux - returns: webserver and other virtual machines that have linux in their excerpts. trigger:excerpts-regex intercosm: macrocosm: microcosm: d-vector: mask: synchroknot:apache|nginx - returns: all virtual machines that have apache and ngnix in their excerpts. trigger:excerpts-regex intercosm: macrocosm: microcosm: d-vector: mask: synchroknot:(a-z).*server - returns: all virtual machines that have characters a to z and end with server. Eg. webserver, appserver, databaseserver etc. trigger:excerpts-regex intercosm: macrocosm: microcosm: d-vector: mask: synchroknot:webserver(0-9) - returns: webserver0 to webserver9 trigger:excerpts-regex intercosm: macrocosm: microcosm: d-vector: mask: synchroknot:webserver1(0-9)|webserver2(0-5) - returns: webserver10 to webserver25 trigger:excerpts-regex intercosm: macrocosm: microcosm: d-vector: mask: synchroknot:(app|web)server1(0-9)|(app|web)server2(0-5) - returns: webserver10 to webserver25 and appserver10 to appserver25 trigger:excerpts-regex intercosm: macrocosm: microcosm: d-vector: mask: synchroknot:(da.*e|m.*a|app|web)server1(0-9)|(da.*e|m.*a|app|web)server2(0-5) - returns: webserver10 to webserver25, appserver10 to appserver25, mediaserver10 to mediaserver25 and databaseserver10 to databaseserver25. Here m.*a & da.*e expands to media and database.
Examples with AND, Range and OR operators:
*** The above examples can be used with an AND operator with a comma [,]. This means multiple OR operators can be matched but the result will only be produced if it also matches an AND operator. *** trigger:excerpts-regex intercosm: macrocosm: microcosm: d-vector: mask: synchroknot:(da.*e|m.*a|app|web)server1(0-9)|(da.*e|m.*a|app|web)server2(0-5),linux - will only return virtual machines between webserver10 to webserver25, appserver10 to appserver25, mediaserver10 to mediaserver25 and databaseserver10 to databaseserver25 that also have linux in their excerpts. All the ones with eg. freebsd, solaris, unix etc will be ignored.
Adding OR operator[s] to an AND operator:
trigger:excerpts-regex intercosm: macrocosm: microcosm: d-vector: mask: synchroknot:(da.*e|m.*a|app|web)server1(0-9)|(da.*e|m.*a|app|web)server2(0-5),linux|freebsd Here the results will only be returned if linux OR freebsd are also present in their excerpts. trigger:excerpts-regex intercosm: macrocosm: microcosm: d-vector: mask: synchroknot:(da.*e|m.*a|app|web)server1(0-9)|(da.*e|m.*a|app|web)server2(0-5),linux|freebsd|unix Here the results will only be returned if linux OR freebsd OR unix are also present in their excerpts.
Examples with Microcosm, Macrocosm and Intercosm:
Microcosm : tag(s) [up to 15 csv] related to where the Spatial Fabric Array is located [eg. city/town, zip code, street etc]. Macrocosm : tag(s) [up to 15 csv] related to region where the Spatial Fabric Array is located [continent, country, state etc]. Intercosm : tag(s) [up to 15 csv] related to row, stack/rack/shelf, CPU type, network type, topology, group/team/provider identification or Blockchain ID for correspondence, management and support. For example, if the Microcosm, Macrocosm and Intercosm was set on Spatial Fabric Arrays like shown in the example below: trigger:spatial-fabric-array-modify spatial-fabric-array:[ip address] intercosm:rack10,id55555 macrocosm:asia,china microcosm:shenzen,zip010101 trigger:spatial-fabric-array-modify spatial-fabric-array:[ip address] intercosm:rack23,id88888 macrocosm:asia,japan microcosm:tokyo,zip24268 trigger:spatial-fabric-array-modify spatial-fabric-array:[ip address] intercosm:rack33,id88888 macrocosm:asia,taiwan microcosm:taipei,zip54668 trigger:spatial-fabric-array-modify spatial-fabric-array:[ip address] intercosm:rack33,id88888 macrocosm:asia,korea microcosm:seoul,zip33368 trigger:spatial-fabric-array-modify spatial-fabric-array:[ip address] intercosm:rack23,id88888 macrocosm:europe,germany microcosm:stuttgart,zip22229 Then, the searches should yield the appropriate results from the following regions & racks/ids: trigger:excerpts-regex intercosm:rack(0-2)(0-9)|stack(0-9)|id55555|id88888|id1000(0-9) macrocosm:japan|china|korea|taiwan|germany microcosm:tokyo|okinawa|beijing|shenzen|taipei|seoul|stuttgart|munich|zip010101|zip22229|zip24268 d-vector: mask: synchroknot:webserver(0-9)(0-9) trigger:excerpts-regex intercosm:rack(0-2)(0-9)|stack(0-9)|id55555|id88888|id1000(0-9) macrocosm:japan|china|korea|taiwan|germany microcosm:tokyo|okinawa|beijing|shenzen|taipei|seoul|stuttgart|munich|zip010101|zip22229|zip24268 d-vector: mask: synchroknot:(da.*e|m.*a|app|web)server1(0-9)|(da.*e|m.*a|app|web)server2(0-5),linux *** Note: you can also set the distance vector and/or mask as needed. ***
Examples with Network Mask :
mask:28.0.0.0/7 mask:28.9.0.0/24 mask:28.100.80.0/24 mask:28.50.0.0/16 mask:28.1.1.0/24 Adding mask to the above example: trigger:excerpts-regex intercosm:rack(0-2)(0-9)|stack(0-9)|id55555|id88888|id1000(0-9) macrocosm:japan|china|korea|taiwan|germany microcosm:tokyo|okinawa|beijing|shenzen|taipei|seoul|stuttgart|zip010101|zip22229|zip24268 d-vector: mask:28.9.0.0/16 synchroknot:(da.*e|m.*a|app|web)server1(0-9)|(da.*e|m.*a|app|web)server2(0-5),linux trigger:excerpts-regex intercosm:rack(0-2)(0-9)|stack(0-9)|id55555|id88888|id1000(0-9) macrocosm:japan|china|korea|taiwan|germany microcosm:tokyo|okinawa|beijing|shenzen|taipei|seoul|stuttgart|zip010101|zip22229|zip24268 d-vector: mask:28.0.0.0/7 synchroknot:(da.*e|m.*a|app|web)server1(0-9)|(da.*e|m.*a|app|web)server2(0-5),linux
║█║ Shoutout :
Shoutouts are presets for excerpts-regex. There are similar separate presets for excerpts with Realtime Cache and Reachout. Up to 50 Shoutouts can be created with the trigger:shoutout-modify. All the Shoutouts are displayed by clicking the "^" symbol above the SynchroKnot Infrastructure Engine input box, or with the trigger:shoutout trigger:shoutout-info gives the information about all the existing Shoutouts. trigger:shoutout-remove removes a Shoutout. The presets created with Shoutout can be also used with Realtime-Cache and Reachout Power Modules saving time and extra effort. The Realtime-Cache equivalent of Shoutouts can be accessed via the ">>" symbol or via trigger:shoutout-rtc, and the Reachout equivalent of Shoutouts can be accessed via the "<<" symbol, or via trigger:reachout. Examples: trigger:shoutout-modify excerpts: spatial-fabric-array: intercosm: macrocosm: microcosm: d-vector: mask: synchroknot:shoutout-0 Fill in the excerpts, intercosm, macrocosm, microcosm, d-vector, mask as needed. Refer to the examples above under the Excerpts section. trigger:shoutout-remove synchroknot:shoutout-0 trigger:shoutout-info
║█║ Distance Vector :
The distance vector comes preset with an optimal value of 0.7 [i.e 700 milliseconds/ms]. You can increase or decrease it as required. The Spatial Fabric Array listens and waits for 700 ms before it processes the response[s] to the request[s] sent out. trigger:spatial-fabric-array-modify spatial-fabric-array:[ip address] d-vector:[0.25 to 3.5] Different Spatial Fabric Arrays can have different distance vectors. For example, logging into Spatial Fabric Array with d-vector:0.3 would result in a faster response from local or near-local network(s). Logging into Spatial Fabric Array with d:vector:0.7 [or more] may accommodate a distributed global network. It is not a simple task determining local/global network responsiveness. The response to a trigger from local/global Spatial Fabric Arrays depends on a lot of factors. The distance and the load [the CPU cycles available at the destination to process the trigger quickly] can be considered the main factors. For fun, using the trigger:excerpts after setting NETEM delay of 300ms [Eg. tc qdisc add dev eth0 root netem delay 300ms] with the preset distance vector [700 milliseconds/ms] there is still a proper response, even if a single core is dedicated to a spatial cluster on a 2 core [~2GHz] 2GB RAM hardware at the destination! This is just an example of our stretching the distance with UDP in difficult real-world situations on low performance hardware for the purposes of testing. With the Power Module Reachout and Realtime Cache, the distance can be stretched by 5x to 10x.

║█║ Inbound & Outbound Traffic Overview To & From Spatial Fabric Satellites to help set up & configure your own switch/router

This section depicts the simplicity of setting up a standard switch/router or a Linux box acting as a switch/router to traverse inbound and outbound traffic to/from the Spatial Fabric Satellite cluster[s]. ■ Block all traffic forwarding on your switch/router and disable and block Spanning Tree Protocol entering and exiting all ports/interfaces. ■ Connect any free Ethernet ports on Spatial Fabric Satellites not part of their internal interconnect topology to your switch/router. For example, if you have 16 Spatial Fabric Satellites, then you can connect 2 - 4 [or more] ports from the Spatial Fabric Satellite cluster to your switch/router. Eg. 1 port from Spatial Fabric Satellite1, 1 port from Spatial Fabric Satellite16 and Spatial Fabric Satellite8 and so on as desired for the purposes of redundancy and traffic load distribution. The Spatial Fabric Satellite traffic is classified into two types: ■ Outbound ■ Inbound
█ Outbound Traffic From Spatial Fabric Satellites
The Outbound traffic from Spatial Fabric Satellites is of 2 types: █ VLAN Tagged: *** All VLAN tagged traffic is Tenant traffic *** Single Stack: 802.1ad [Ethertype 0x88a8] Double Stack: 802.1q [Ethertype 0x8100] - 802.1ad + 802.1q Triple Stack: 802.1q [Ethertype 0x8100] - 802.1ad + 802.1q + 802.1q a] Connect the Ethernet port[s] to your IPv4/IPv6 Router/Gateway. b] Untag the VLAN that was given to the Tenant when creating the Spatial Cluster [i.e interstellar], and block all traffic going in and out of the VLAN. c] Only allow the public IPv4/IPv6 subnet [including ARP for IPv4] given to the Tenant to traverse and flow on to your IPv4/IPv6 Router/Gateway ports. Thats it! Example of setting up a Single Stack VLAN [55] with 802.1ad and a Double Stack VLAN [802.1ad + 802.1q] 55.100 using the ip link command on Linux: ip link add link eth0 eth0.55 type vlan proto 802.1ad id 55 ip link add link eth0.55 eth0.55.100 type vlan proto 802.1Q id 100 █ Untagged *** All untagged traffic is SynchroKnot Spatial Fabric Satellite internal traffic. *** a] Connect an Ethernet port to your layer 2 Provider VPN [Eg. TINC peer-to-peer VPN] that connects all the sites with Spatial Fabric Satellites. Read Layer 2 Peer-to-Peer VPN and Spatial Fabric Satellite Interconnection Across Multiple Sites By The Infrastructure Provider b] Block all traffic, and only allow the 28.0.0.0/7 and 10.0.0.0/7 subnets along with their unicast/broadcast/ARP traffic to traverse and flow on to your Provider VPN [TINC] port. Thats it!
█ Inbound Traffic Towards Spatial Fabric Satellites
*** All Inbound traffic coming from your Tenant VPN can either be untagged or tagged. If the traffic is tagged then you must untag it at your switch or router. You can set up any layer3/2 VPN of your choice acting as a Tenant VPN where your Tenants can remotely connect. *** a] Connect the Ethernet port from your Tenant VPN. b] Block all traffic from/to the Tenant VPN port. Only allow traffic with the destination IP subnet 10.0.0.0/7 [along with ARP traffic] to traverse and flow on to the ports connected to the Spatial Fabric Satellites. If some or all Tenants need to be given access to all distributed sites, then allow the subnets given to the Tenants to traverse and flow on to the Provider VPN port. c] The Tenants can be assigned subnets in the 192.168.x.x & 172.16.x.x. As a standard practice, the Tenant traffic must be separated and must not communicate with each other. The destination IP [and ARP] subnet allowed of the Tenant traffic must only be 10.0.0.0/7. *** The Tenant traffic can either be routed or NATed. *** *IMPORTANT*: If the Tenant traffic is NATed, then it has to be a 1:1 NAT [see example below]. To achieve this, a public IP address range [Eg. 240.0.0.0 public IP range that is unused & reserved for future use] can be used as a private address and a 1:1 NAT can be set up. The Tenants can be given the IP subnets from 240.0.x.x to 240.8.x.x. In this 1:1 NAT example [240.0.0.0/7 mapped to 10.0.0.0/7], the Spatial Fabric Satellites must be given IP addresses other than those reserved for the Tenants. For example, Spatial Fabric Satellites can be given IP addresses in the 28.9.x.x range and above [which will also have their corresponding IP addresses in the 10.9.x.x range and above]. Thats it! The Tenants will be able to access the local and distributed Infrastructure Engine, Storage Datapath Access, etc. on any authorized Spatial Fabric Satellite where they have a Spatial Cluster. Examples of NAT 1:1 mapping with Netfilter [IPTables Netmap]: iptables -t nat -A PREROUTING -d 240.0.0.0/7 -i eth0 -j NETMAP --to 10.0.0.0/7 iptables -t nat -A POSTROUTING -s 10.0.0.0/7 -o eth0 -j NETMAP --to 240.0.0.0/7 Replace eth0 with the interface connected to your Tenant VPN on your switch/router OR with the interface on your Tenant VPN itself that is connected to your switch/router. Make sure that the Tenant subnets do not communicate with each other, and the packets coming in from the Tenant VPN have a destination IP subnet other than 240.0.x.x to 240.8.0.0 range [as this range is given to the Tenants in this example]. You can customize this example to suit the needs of your setup. SynchroKnot automatically takes care of and handles redirects with combination of partly server-side + partly server-side-embedded-client-side functionality so that the traffic behind the NAT can still reach its destination when a redirect is requested from the Infrastructure Engine on the Spatial Fabric Satellite [which is on the other side of the NAT]. Read SynchroKnot Auto NAT Enablement
║█║ Layer 2 Peer-to-Peer VPN :
The infrastructure provider(s) can use any layer 2 VPN [preferably it should be peer-to-peer] to interconnect sites with Spatial Fabric Satellites. ***Satellte Tree Protocol *MUST* be blocked from getting in and out of the VPN. In other words, neither site should let the Satellite Tree Protocol reach the other site[s]. There is no harm if it does, but it might reduce the scalability and increase the optimal path selection time in certain situations, as metadata of the local site will be propagated across all the other sites.*** The Tenants can also use layer 2 peer-to-peer VPN inside their virtual machine[s] to simply connect their local/global site(s) separate and independent of the infrastructure provider(s) and not have to do anything related to Satellte Tree Protocol or any other aspect. TINC is a peer-to-peer VPN which is widely used. It is known to have good performance, plus it is mature and stable. This makes it an ideal VPN solution to use with SynchroKnot. If you choose TINC then keep the following in mind : ■ Read : "Example: bridging Ethernet segments using tinc under Linux" [using the switch mode] on the official TINC website. ■ If the total sites connected are 50 - 100 or more, then set up 5 - 15 nodes [or more depending upon your setup] as the "connect to" peers or C2-Peer. Here every TINC node will only connect to the C2-Peers with the "connect-to=" option, allowing you to scale. Without the C2-Peers, every node might connect to eachother and notify eachother every time a new node joins and leaves, generating a lot of metadata, among other things. This can cause a load on the network, as some nodes might experience spiked cpu, memory and bandwidth usage. ■ Adjust the MTU if needed when allowing single/double/triple stacked VLANs to traverse [see scenario 1 below]. ■ Use hardware with enough fast cpus and memory, and needless to say, enough bandwidth. ■ Set up a virtual machine for TINC pre-configured as a Spacesuit for the Tenants with instructions on how to use it as a gateway to quickly interconnect their sites. ■ If different infrastructure providers share sites, then make sure that there is an understanding such that the IP addresses of the Spatial Fabric Satellites don't clash. ■ That's it!
║█║ Spatial Fabric Satellite Interconnection Across Multiple Sites By The Infrastructure Provider :
Communication between Spatial Fabric Satellites is untagged [no VLAN tags used] with IP addresses assigned in the 28.0.0.0/7 range. The Infrastructure Provider can use layer 2 loop-free VPN [see above] to connect dispersed sites/locations. ■ IP addresses of all Spatial Fabric Satellites must be unique and in the 28.0.0.0/7 range. ■ Layer 2 traffic [mainly, IPv4 UDP unicast, UDP broadcast, ARP and TCP from and to the 28.0.0.0/7 range and 10.0.0.0/7 range] needs to be transparently reachable across the VPN like the local network. ■ Spanning Tree Protocol [STP] *MUST* be blocked and *MUST NOT* be allowed to traverse across the sites connected via a VPN. ■ ***Scenario 2 and 3 seem more optimal from managing, scaling and flexibility points of view without having the infrastructure provider manage Tenant network [i.e VPN, co-ordination of VLANs across sites, maintenance of Tenant inter-site connectivity etc].*** ■ As mentioned before, It is *NOT* necessary to create the same Spatial Cluster on all Spatial Fabric Satellites. General details of the 28.0.0.0/7 network: IP Address: 28.0.0.0 Network Address: 28.0.0.0 CIDR Notation: /7 Usable Host IP Range: 28.0.0.1 - 29.255.255.254 Broadcast Address: 29.255.255.255 Total Number of Hosts: 33,554,432 Number of Usable Hosts: 33,554,430 Subnet Mask: 254.0.0.0
█ Example : Scenario 1 : * Not Recommended *
*** Just One Simple Step - Connect all needed sites with a Layer 2 VPN *** [Please read "Layer 2 Peer-to-Peer VPN" above.] ■ *All traffic* except Spanning Tree Protocol [STP] is allowed to traverse the VPN. ■ Each spatial cluster must be created with the same VLAN ID across all sites. ■ The MTU of the VPN may need to be adjusted to allow single, double or triple stacked Vlans to traverse. Plus, since most VPNs may not be able to look into the source/destination fields of the packets/frames with VLAN tags there are chances that those packets/frames might be broadcasted. Please ascertain your use case scenario carefully. 6 dispersed sites with 10 Spatial Fabric Satellites each -- All sites interconnected via a layer 2 VPN by the same infrastructure provider OR separate infrastructure providers with an understanding of the IP address [28.0.0.0/7] range they can use. Spatial Cluster for Tenant ABC is created on all 60 Spatial Fabric Satellites with the *SAME* VLAN ID. Then, Tenant ABC can log into any [or all] Spatial Fabric Satellite[s] and manage virtual infrastructure across all 60 Spatial Fabric Satellites across all the sites seamlessly. The virtual infrastructure [ie virtual machines of Tenant ABC] across all the 6 sites *WILL* also be connected.
█ Example : Scenario 2 : *** Highly Recommended ***
*** Just One Simple Step - Connect all needed sites with a Layer 2 VPN *** [Please read "Layer 2 Peer-to-Peer VPN" above.] *** DO NOT allow single, double or triple stacked VLANS and Spanning Tree Protocol [STP] to traverse the VPN. That's all there is to it! *** Spatial Cluster for Tenant ABC is created on any/all Spatial Fabric Satellites as needed across the 6 dispersed sites. *** Each site can assign the *SAME* OR *DIFFERENT* VLAN ID to the spatial cluster. There is no need for the infrastructure providers at different sites to co-ordinate regarding VLAN IDs or other aspects!!! *** The Tenant will be able to transparently and seamlessly manage their virtual machines and other aspects of their virtual infrastructure from any Spatial Fabric Satellite. SynchroKnot provides the unique ability to perform ANY-to-ANY management. The virtual machines can communicate with each other within their respective sites. The virtual machines across the sites *WILL NOT* be connected and cannot communicate unless the Tenant specifically chooses to do so, in which case, the Tenants can use layer 2 peer-to-peer VPN [eg. TINC] inside a virtual machine acting as a VPN Gateway on one site to simply connect their local/global dispersed sites or for that matter any site running on public/private cloud or physical infrastructure! This gives Tenants full interconnection specificity and flexibility. The Infrastructure Provider[s] do not have to manage the Tenant networks [i.e Tenant VPNs, VLANs across sites and much more]. Since the network of the Tenant [i.e the spatial cluster] is based on Ethernet Layer 2, the Tenant[s] are free to use any IP addressing or non-IP addressing schemes in their virtual machines, and all software applications that run on network Layer 2 and above should work transparently! Example: Infrastructure Provider at site 1 creates a spatial cluster 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE with VLAN 100 on the needed spatial fabric satellites, and the same/other Infrastructure Provider at site 2 creates spatial cluster 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE with VLAN 200.200, and so on. Then, Tenant ABC can log into any one [or all] Spatial Fabric Satellite[s] on any site[s] and manage all virtual machines and related aspects dispersed across all 6 sites seamlessly and transparently as if they were local. As mentioned above, the virtual machines of the Tenant across all the 6 sites *WILL NOT* be connected unless the Tenant specifically chooses to. Read Gateway for Customer / Tenant Inbound and Outbound traffic below for more information.
█ Example : Scenario 3 :
2 dispersed sites with 10 Spatial Fabric Satellites each -- The Spatial Fabric Satellites at these 2 sites are *NOT* interconnected [eg. separate infrastructure providers]. Spatial Cluster for Tenant ABC is created on all 10 Spatial Fabric Satellites on site 1 and all 10 Spatial Fabric Satellites on site 2. The Tenant ABC *CANNOT* seamlessly manage the virtual infrastructure on site 1 and site 2, but can separately manage it by logging in separately [eg. 2 browser tabs] into any [or all] Spatial Fabric Satellite(s) on site 1 and site 2. The Tenant can choose to connect virtual infrastructure on site 1, site 2 or any other site with a VPN.

║█║ Spatial Fabric Traverser with Intersecter : Power Module

█ Spatial Fabric Traverser is a SynchroKnot Software that:
■ Connects the Spatial Fabric Satellites to the Public Internet Gateway Router[s]/Switch[es], Provider VPN [i.e VPN that connects the sites of the provider] and Tenant VPN [i.e VPN where the Tenants remotely connect] with a quick and minimal set up. ■ Transparently traverses traffic from both Public IPv4 and IPv6 addresses to/from single/multiple Internet service providers to/from spatial clusters on Spatial Fabric Satelltes. ■ Takes care of all single/double/triple stacked VLAN traffic traversing from spatial clusters on Spatial Fabric Satellites to single/multiple Public Internet Gateways [IPv4/IPv6] from single/multiple Internet service providers. ■ Serves as a simple, fault-tolerant alternative to using standard routers/switches. ■ Installs on any AMD64 hardware with multiple Ethernet network ports [has same operating system requirements as Spatial Fabric Satellites]. ■ All modifications to the IPv4 and IPv6 blocks can be made at the same time and without disrupting the traffic flow of all existing IPv4/IPv6 blocks to/from spatial clusters. Each Spatial Fabric Traverser can be connected to multiple Public Internet Gateways, which means, Tenants [spatial clusters] that have been given specific public IPv4/IPv6 address blocks can reach their public Internet Gateways across different Internet service providers. With Spatial Fabric Traverser, each spatial cluster can be given IPv4/IPv6 address blocks from different Internet service providers if needed! Multiple Spatial Fabric Traversers can be set up for fault-tolerance and load balancing with Satellite Tree Protocol [built-in]. Note: Depending on the use case scenario, the Power Module Spaceway may not be needed if the Spatial Fabric Traverser is used.
█ Intersecter:
■ Is a part of the Spatial Fabric Traverser. It interconnects separate physical clusters of Spatial Fabric Satellites transparently while keeping their Satellite Tree Protocol Domains separated. ■ Does not allow one large Satellite Tree Protocol domain to form across different physical clusters of Spatial Fabric Satellites when they are interconnected, allowing for the ease of maintenance, expansion, contraction and troubleshooting.
█ Triggers to Control and Manage Spatial Fabric Traverser and Intersecter:
█ Set up Traverser
Sets up Traverser. echo "trigger:setup-traverser ports:[port[s] facing Spatial Fabric Satellites] traverser-ports:[port[s] facing Internet Gateway[s]]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl The key traverser-ports: are Internet Gateway facing, and the key ports: holds the Spatial Fabric Satellite facing ports. Connect any free Ethernet port[s] from the Spatial Fabric Satellte cluster that are not a part of their internal interconnect topology to the Traverser [i.e Spatial Fabric Satellite facing ports]. Eg. If there are 16 Spatial Fabric Satelltes interconnected to eachother in a Ring/Torus/custom mixed topology, use any free Ethernet port[s] from 1 to 4 [or more] Spatial Fabric Satelltes of choice and connect them to any available Spatial Fabric Satellite facing ports on the Traverser. No manual configuration needed! To modify Traverser, use trigger:setup-traverser. The operating system will need to be rebooted to use the trigger:invoke-traverser as realtime modification is currently not supported for Traverser.
█ Set up Outbound and Inbound Ports
After the Spatial Fabric Traverser is set up as shown above, the Outbound and Inbound ports can be set up if needed. The Outbound port is connected to the Provider VPN [Eg. TINC] which connects the sites of the provider. The Inbound port is connected to the Tenant VPN. The Tenant VPN allows Tenants to remotely connect. Choose any free port assigned to the Spatial Fabric Satellites [i.e the key "ports:" when using the "trigger:setup-traverser"] to be enabled as an Inbound and Outbound port. Example: echo "trigger:modify-outbound outbound:[any free port facing Spatial Fabric Satellites]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl echo "trigger:modify-inbound inbound:[any free port facing Spatial Fabric Satellites]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl To modify the inbound or outbound port follow the steps shown above.
█ Invoke Traverser
Invokes the traverser into operational mode. echo "trigger:invoke-traverser" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl
█ Info Traverser
Shows the Ethernet ports assigned to the Traverser and Intersecter. echo "trigger:info-traverser" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl
█ Add Interstellar
Adds single or multiple [CSV] Interstellars. echo "trigger:add-interstellar interstellar:[single/double/triple stacked VLANS CSV]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl Example: echo "trigger:add-interstellar interstellar:100,222.222,555.555.555,1000" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl
█ Remove Interstellar
Removes single or multiple [CSV] Interstellars. echo "trigger:remove-interstellar interstellar:[single/double/triple stacked VLANS CSV]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl
█ Info Interstellar
Shows information of a single Interstellar. echo "trigger:info-interstellar interstellar:[one single/double/triple stacked VLAN]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl
█ List Interstellar
Lists all available Interstellars. echo "trigger:list-interstellar" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl
█ Start Interstellar
Starts a single Interstellar. echo "trigger:start-interstellar interstellar:[one single/double/triple stacked VLAN]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl
█ Stop Interstellar
Stops a single Interstellar. echo "trigger:stop-interstellar interstellar:[one single/double/triple stacked VLAN]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl
█ Modify Interstellar
Modifies a single Interstellar. echo "trigger:modify-interstellar interstellar:[one single/double/triple stacked VLAN] ipv4:[ipv4 blocks CSV] ipv6:[ipv6 blocks CSV] ipv6-icmp-type:[ICMP Types CSV]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl Setting a blank value to the keys ipv4, ipv6 and ipv6-icmp-type removes their assigned value. Example of IPv4 & IPv6: ipv4:111.111.111.0/24,222.222.222.0/24 ipv6:2001.0db8.100.1.2.3.4.5/48 The following ICMP Types are supported: destination-unreachable no-route communication-prohibited address-unreachable port-unreachable packet-too-big time-exceeded ttl-zero-during-transit ttl-zero-during-reassembly parameter-problem bad-header unknown-header-type unknown-option echo-request echo-reply router-solicitation router-advertisement neighbour-solicitation neighbour-advertisement redirect Note: If the value for the key ipv6-icmp-type: is blank, then the following ICMP Types are automatically assigned if valid IPv6 block[s] are found for that interstellar: destination-unreachable no-route address-unreachable port-unreachable echo-request echo-reply router-solicitation router-advertisement neighbour-solicitation neighbour-advertisement
█ Modify Interstellar Realtime
Modifies a single Interstellar in realtime without affecting or disturbing its traffic flow, and also without affecting or disturbing the traffic flow of other Interstellars. For example, if the IPv4 blocks assigned to Interstellar 1000 are 111.111.111.0/24,222.222.222.0/24 and you add another block 99.99.99.0/24, then the traffic from virtual machines using the blocks 111.111.111.0/24 and 222.222.222.0/24 will not be affected/disrupted. Likewise, if block 99.99.99.0/24 was added and the block 111.111.111.0/24 was removed, then the traffic from the virtual machines that use the block 222.222.222.0/24 will not be affected/disrupted. echo "trigger:modify-interstellar-rt ipv4:[ipv4 blocks CSV] ipv6:[ipv6 blocks CSV] ipv6-icmp-type:[ICMP Types CSV]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl
█ Setup Intersecter
Sets up the Intersecter. echo "trigger:setup-intersecter intersecter-ports:[unused free ports]" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl Note: Please make sure that the ports are not assigned to Traverser [though an internal check is performed for already assigned Ethernet ports]. To modify Intersecter do the same as above, but the operating system will need to be rebooted to use the trigger:invoke-intersecter as realtime modification is currently not supported for the Intersecter and Traverser.
█ Invoke Interstellar
Invokes the Intersecter into operational mode. echo "trigger:invoke-intersecter" | /tier0/spatial-fabric-traverser/spatial-fabric-traverser.ctl

║█║ Spaceway : Power Module

The Synchroknot Spaceway is a power module that is designed for the Spatial Fabric Satellites. It allows the Spatial Fabric Satellites to allow specific public IPv4 and/or IPv6 address block[s] to traverse and reach their Spatial Clusters. With Spaceway, the outbound traffic from the virtual machines can reach their gateway[s] with public IP addresses, and the inbound traffic can reach the virtual machines from their public IP gateway[s]. The Spaceway removes the need for setting up a router/switch that can tag/untag single/double/triple stacked VLANs and the performing of other complex configurations and their maintenance. To use Spaceway you need: ■ Public IPv4 and/or IPv6 addresses, and have them associated with a spatial cluster on the Spatial Fabric Satellite. ■ The Spaceway port must be connected to the router that has or points to the gateway with public IP address[es]. Then, the virtual machines of that spatial cluster will have inbound and outbound access to and from the Internet. Spaceway can be invoked on multiple Spatial Fabric Satellites. Different Spaceways can be invoked for different spatial clusters on single or multiple Spatial Fabric Satellites. If a Spaceway for a specific spatial cluster is created on two or more Spatial Fabric Satellites, then the virtual machines from that spatial cluster will have multiple fault-tolerant paths to reach their gateways. Important: A Spaceway port on a single or multiple Spatial Fabric Satellites can be conected to a standard router [Layer 3]. If using a switch [layer 2], it is important that the traffic does not loop back and STP is turned off. If you would like to have your own powerful solution in the simplest possible steps please take a look at SynchroKnot Spatial Fabric Traverser. Note: Depending on use the case scenario, the Power Module Spaceway may not be need if the Spatial Fabric Traverser is used.
█ Spaceway Setup
To set up a Spaceway, assign a network port that is not assigned to the Spatial Fabric Satellite to be a part of its internal interconnect topology. Though more than one free port [csv] can be assigned to the Spaceway, it is recommended to assign to it only one free port. This is a one-time operation, unless the network port is desired to be modified. echo "trigger:setup ports:eth4" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt
█ Spaceway Invoke
The Spaceway needs to be invoked before it can be used. This operation is required every time the Spaceway is first started [Eg. after the Spatial Fabric Satellite boots up]. echo "trigger:invoke" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt
█ Spaceway Construct
Spaceway "construct" creates a Spaceway for a particular spatial cluster. IPv4 and/or IPv6 blocks [csv] can be assigned to a specific spatial cluster. echo "trigger:construct spatial-cluster:[spatial cluster Blockchain Id] ipv4:[csv IPv4 blocks] ipv6:[csv IPv6 blocks" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt Important: When using IPv6 blocks, remember to change the : to a . Example: echo "trigger:construct spatial-cluster:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE ipv4:111.111.111.0/24,222.222.222.0/24 ipv6:2001.0db8.100.1.2.3.4.5/48" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt
█ Spaceway Start
Spaceway "start" starts the Spaceway for the specific spatial cluster for which it was created, and only allows the public IPv4 and/or IPv6 blocks assigned to that spatial cluster to traverse. echo "trigger:start spatial-cluster:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt
█ Spaceway Modify
Spaceway "modify" transparently modifies the IPv4 and/or IPv6 address blocks. All operations are performed without disrupting the existing blocks that are not modified. For example, if the IPv4 blocks assigned to the spatial cluster 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE are 111.111.111.0/24,222.222.222.0/24 and you add another block 99.99.99.0/24, then the traffic from virtual machines using the blocks 111.111.111.0/24 and 222.222.222.0/24 will not be affected/disrupted. Likewise, if block 99.99.99.0/24 was added and the block 111.111.111.0/24 was removed, then the traffic from the virtual machines that use the block 222.222.222.0/24 will not be affected/disrupted. To completely remove the IPv4 and/or IPv6 blocks let the value for the keys ipv4 and ipv6 be blank. Eg ipv4: ipv6: Important: When using IPv6 blocks, remember to change the : to a . Examples: Adding 99.99.99.0/24 to the existing blocks 111.111.111.0/24 and 222.222.222.0/24. The csv can be in any order. echo "trigger:modify spatial-cluster:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE ipv4:111.111.111.0/24,222.222.222.0/24,99.99.99.0/24" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt In the above example, the ipv4 block 99.99.99.0/24 is added to the existing blocks 111.111.111.0/24 and 222.222.222.0/24 without disruption. echo "trigger:modify spatial-cluster:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE ipv4:99.99.99.0/24,111.111.111.0/24" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt In the above example, the ipv4 block 222.222.222.0/24 is removed without disrupting the blocks 99.99.99.0/24 and 111.111.111.0/24 Note: All non-disrupting changes can be made to IPv4 and IPv6 blocks at the same time.
█ Spaceway Stop
Spaceway "stop" stops the Spaceway for the specific spatial cluster for which it was created. All traversing traffic will be dropped instantly. echo "trigger:stop spatial-cluster:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt
█ Spaceway Deconstruct
Spaceway "deconstruct" completely removes the Spaceway after automatically stopping it if it was started. echo "trigger:deconstruct spatial-cluster:[spatial cluster Blockchain Id]" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt Example: echo "trigger:deconstruct spatial-cluster:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt
█ Spaceway Info
Spaceway "info" returns the IPv4 and IPv6 blocks associated with the spatial cluster. echo "trigger:info spatial-cluster:1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE" | /tier0/synchroknot/www/synchroknot-modules/spaceway-power-module.sknt
║█║ Gateway for Customer / Tenant Inbound and Outbound Traffic to and from the Spatial Fabric Satellite(s) :
One can use SynchroKnot Spatial Fabric Traverser OR Spaceway, OR a standard switch/router, or a Linux box to act as a router/gateway that adds and removes VLAN tags coming in from the Spatial Cluster(s) on the Spatial Fabric Satellite(s). █ Level 1 tag [i.e base tag] is always 802.1ad [Ethertype 0x88a8]. █ Level 2 and level 3 tags are 802.1q [Ethertype 0x8100].
Step 1:
Block all traffic going in and coming out of the interface with the VLAN tag that is assigned to a Customer/Tenant.
Step 2:
*ONLY THEN* allow the public IP address [IPv4/IPv6] range/subnet that was alloted to the Tenant to traverse. That's all there is to it! *** This means ZERO management of the Tenant networks by the Infrastructure Provider. *** * The Tenants set up and manage their own VPN. * Multiple Ethernet ports from the Spatial Fabric Satellites that are not used as a part of the their interconnect topology can be connected to the gateway(s). Spanning Tree Protocol, Rapid Spanning Tree Protocol or similar other protocol traffic *MUST NOT* reach the Spatial Fabric Satellites from the gateway(s). The gateway(s) *MUST NOT* loop traffic back to Spatial Fabric Satellites. Example Scenario : On site A, the Infrastructure Provider creates 4 spatial clusters [on 4 Spatial Fabric Satellites] for Tenant abc with the blockchain id 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z and interstellar 1000.1000.1000 [triple stacked VLAN], and then allots for example, public IP addresses in the range 111.111.111.0/24. The provider, before giving out this IP range to the Tenant, blocks all traffic at the gateway that tags/untags VLAN 1000.1000.1000, and only allows the IP range 111.111.111.0/24 to go in and out of the interface with the VLAN tag 1000.1000.1000. That's it! The Tenant can then set up their own VPN in a virtual machine and get global direct connection to any number of sites regardless of the underlying provider. Let's say here the client connects to site B and C where the same Spatial Cluster 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z is running on VLANs 999.999 and 234 on sites B and C respectively. There is no need to coordinate between the infrastructure providers regarding VLANs or any other aspect regarding Spatial Fabric Satellites. Also, there is no need for BGP peering and other complexities. With the SynchroKnot product, 802.1ad [Ethertype 0x88a8] *IS NOT* used the same way it is used with Metro Ethernet [i.e service and customer VLAN IDs] across various connection brokers/providers providing interconnection and BGP peering between various customer and cloud provider sites. With the SynchroKnot product, up to triple-stacked VLANs are used in just one site! The Infrastructure Provider for example, can charge the Tenant(s) for the infrastructure and bandwidth, and now gets the flexible option to choose the least expensive Internet bandwidth available, and also load balance inbound and outbound traffic across multiple bandwidth links/connections.

║█║ Infrastructure Engine :

The Infrastructure Engine can be accessed by all Tenants in the 10.0.0.0/7 range corresponding to the 28.0.0.0/7 range IP address given to the Spatial Fabric Satellite. Eg. https://10.9.0.1/SynchroKnot.sknt If the user is logging in for the first time or has cleared the browser cookies, he/she will be automatically taken to the SynchroKnot-Identify.sknt page to log in and then brought back to the Infrastructure Engine landing page on success. *** There MUST NOT be a space between the key and value pair separated by a : [Eg. key:value]. *** *** There MUST ALWAYS be a "space" between the "sets" of key and value pairs [Eg. key1:value1 key2:value2 key3:value3 etc]. *** ■ To log in use your Bitcoin Address as username, your private key and the Bitcoin Address of the spatial cluster. If you do not exist or your ID is disabled you will not be able to log in. ■ To log out use trigger:eject and to get license information use trigger:license. ■ To clear/undo the trigger use ctrl+z. ■ To set appropriate screen font size use ctrl- to reduce and ctrl+ to increase the font size. Some browsers have a default large font size which may not be efficient. ■ To move the cursor quickly across the input box use ctrl+left/right arrow key. ■ To move the cursor to the start and end of the input box use Fn+left/right arrow key. ■ The trigger input box automatically expands and contracts adjusting to the length of the triggers. ■ When only using the keyboard, use ctrl + enter key to successfully trigger. This feature greatly reduces the chances of mishaps caused by accidental triggering. ■ Tested on Firefox [52.2.0 and above on Linux 64-bit], should work on modern Webkit-based web browsers with Javascript enabled. ■ The virtual machine console access using Java applet will only work in the browser[s] with version[s] that support Java applets.
█ Basic Usage:
■ Click "SYNCHROKNOT" to get all the virtual machines present in your spatial cluster across all the Spatial Fabric Satellites. ■ Click directly below "SYNCHROKNOT" [invisible area seen with mouseover] to instantly get all the virtual machines present in your spatial cluster across all the Spatial Fabric Satellites using Real-Time Cache [Power Module]. ■ Click directly below the input box [invisible area seen with mouseover] to append the excerpts-regex trigger [the most likely used trigger] to the input box. ■ Click "^" symbol [or use trigger:shoutout] to instantly access Shoutouts. ■ Click ">>" symbol [or use trigger:shoutout-rtc] to instantly access Shoutouts with Realtime Cache [Power Module]. ■ Click "<<" symbol [or use trigger:reachout] to instantly access Shoutouts with Reachout [Power Module]. Note: Shoutouts will only be displayed if they were previously created with trigger:shoutout-modify. Please read the Shoutout section.
Dual Purpose On-Page Sift:
Dual Purpose On-Page Sift is a unique feature of the SynchroKnot Infrastructure Engine that speeds-up on-page search operations by reducing the time and effort required. Dual Purpose On-Page Sift does two things in parallel when typed in the Input Box: 1] Automatically searches for "SynchroKnot Triggers" [after the minimum count of 5 characters]. 2] Automatically searches for virtual machine names that have appeared on the page as a result of the excerpts trigger [eg. regex|rtc|reachout etc] by immediately fading away the unmatched results in real-time as the search string is being typed. The virtual machine names reappear when the search string is reduced or removed [Eg. using "Back Space"]. Note: Simply hit the "Escape Key" [or continue to type through] to temporarily deactivate the "SynchroKnot Trigger Search" after 5 characters if by some chance the virtual machine search string might contain characters that also belong to the "SynchroKnot Triggers"!
█ Basic Usage of "Shortcuts" with Virtual Machine Information [i.e trigger:vm-info] and Other Triggers:
Shortcuts are convenient. They save space on the input box and greatly reduce time and effort when initiating triggers! ■ Short name for the key spatial-fabric-array: is sfa: [defaults to sfa:] ■ Short name for the key power-module: is pm: [defaults to pm:] ■ Mouse-over on the IP address of the Spatial Fabric Array says "Append to sfa:"; on clicking, the IP address gets added to the key sfa: without disturbing all the other keys and values. ■ Mouse-over on the Blockchain ID [ Bitcoin Address] of the virtual machine says "Append + as a shortcut for virtual machine name to synchroknot:" ; on clicking the Blockchain ID a "+" gets added to the key synchroknot: without disturbing all the other keys and values. Here SynchroKnot will automatically translate "+" to the virtual machine's full name internally. ■ Mouse-over on the first name of the virtual machine says "Append virtual machine name to synchroknot:" ; on clicking the virtual machine name, the full name of the virtual machine [first + last] gets added to the key synchroknot: without disturbing all the other keys and values. ■ Mouse-over on "█║▌║▌║" says "Append to spacesuit:" ; on clicking the symbol, the full name of the virtual machine [first + last] gets added to the key spacesuit: without disturbing all the other keys and values. Here a "+" can also be added to the key spacesuit: as a shortcut to the full name of the virtual machine. Note: If there happens to be a value already given to a key, then that value will be non-disruptively replaced by the new value. █ IMPORTANT: ■ SynchroKnot *DOES NOT* connect/use the Bitcoin network or other external network(s) to perform any task. Power Module(s) in the future may use it, in which case it will be explicitly mentioned. ■ Your Bitcoin Private Key is *NOT* sent to the server. It is *ONLY* used in the browser to sign a Spatial Nonce Fingerprint [ invisible to the user ]. ■ Your Bitcoin Private Key *MUST NOT* be shared with anyone and you *MUST ONLY* be logging in to a trusted Infrastructure Provider.
║█║ Spacesuit :
Virtual Machine Spacesuit : This is a template of the virtual machine from which new virtual machines can be created. One can create a spacesuit from an existing spacesuit or a virtual machine, and configure its encrypted configuration vault [also called the spacesuit]. The virtual machine spacesuit is identified by its yellow icon and by its naming scheme. Eg. {name}-ss0, {name}-spacesuit0 etc. Each virtual machine and a user [ie. synchroknot with a Bitcoin ID] has an encrypted vault also called spacesuit which stores the configuration and metadata. These configurations can be modified with trigger:vm-modify for the virtual machine and trigger:synchroknot-modify for the user [see below].
║█║ Spatial Virtual Machine :
QEMU virtual machines [with default KVM enabled] are known by their fullname [firstname-lastname]. The firstname is the name given to it and the lastname is a Blockchain ID that is automatically generated along with its private key. Make sure you use the correct QEMU options where required, and that the virtual machine's operating system supports those options [eg. drivers, crtl-alt-del, power down etc] for successful boot and operations. When in doubt or experiencing potential issues, it is recommended that the virtual machines be tested with the QEMU commandline and assessed for its appropriate workability, and only then incorporate the necessary QEMU options with trigger:vm-modify It is important that you give the virtual machines a unique first name [though multiple virtual machines with the same first name will work, but will cause serious management and operational issues]. Tenants are advised to maintain a list or database of virtual machines and user names that are used. This may be used for auditing against the virtual infrastructure. Eg. {vmname},{spatial fabric array},{nicx-ip},{nicx-gateway-ip},{excerpts},{interstellar and interstellar resonance ids},{location} | {user blockchain id},{privilege},{name},{contact},{spatial fabric array},{location} For real-time monitoring, stats, and alerts Netdata will have to be installed directly in the virtual machines. The Tenant will need a path/route [direct/VPN] from his/her machine to access the Netdata port on the virtual machine. Please refer to the Netdata manual. Refer to video demonstration.
█ Create
█ A new virtual machine can be created in the following ways:From a spacesuit. This spacesuit may be in a stopped, paused or running state and the new virtual machine created from it will be created without any interruption or disruption to the existing spacesuit. Just the first name of the Spacesuit is required. ■ From an existing virtual machine using it as a spacesuit. The existing virtual machine can be in a stopped, paused or running state and the new virtual machine created from it will be created without any interruption or disruption to the existing virtual machine. ■ A virtual machine is automatically created on a Spatial Fabric Array with the best resources if the key spatial-fabric-array: is blank. The spacesuit needs to be present on Spatial Fabric Array[s] for the virtual machine to be auto-created. Fine-grained specifics such as Intercosm, Microcosm, Macrocosm, Mask and Performance are supported! trigger:vm-create spacesuit:[first name of spacesuit] intercosm: macrocosm: microcosm: mask: performance:[blank refers to high|high|low] synchroknot:[name of the new virtual machine] ■ If a virtual machine needs to be created on a specific Spatial Fabric Array, then the key spatial-fabric-array: needs value of an IP address. The spacesuit [template with the yellow icon] or the virtual machine acting as a spacesuit needs to be present there. If not, you can create a virtual machine on a Spatial Fabric Array that has that spacesuit or virtual machine [chosen to be used as a spacesuit], and then [auto/manual] relocate it. For example, you have 5 Spatial Fabric Arrays and all of them have a spacesuit called debian as the firstname and different lastnames. You can create [auto/manual] virtual machines across all 5 Spatial Fabric Arrays. Now, if you only had spacesuit debian on Spatial Fabric Arrays 1 and 2, then virtual machines can only be created [auto/manual] on Spatial Fabric Arrays 1 and 2, and then relocated [auto/manual] if necessary. trigger:vm-create origin: spacesuit: spatial-fabric-array: synchroknot: ■ Name must be 30 characters or below and can only have these legal characters [numbers, a to z and -] without spaces: - 0-9 a-z ■ The name of the spacesuit from which the virtual machine is to be created can just be its first name if it is an actual virtual machine spacesuit. [It does not matter if the same spacesuit exists on different Spatial Fabric Arrays with different lastnames, SynchroKnot automatically takes care of that complexity.] █ A Spacesuit can be created in the following ways:From an existing spacesuit which may be in a stopped, paused or running state without any interruption or disruption to the existing spacesuit. Fullname of the Spacesuit and the IP address of the Spatial Fabric Array where the Spacesuit is present are required. trigger:vm-create type:spacesuit origin:spacesuit spacesuit:[fullname of the existing spacesuit] spatial-fabric-array: synchroknot:[name of the new spacesuit] ■ From a virtual machine which may be in a stopped, paused or running state without any interruption or disruption to the existing virtual machine. Fullname of the virtual machine and the IP address of the Spatial Fabric Array where the virtual machine is present are required. trigger:vm-create type:spacesuit origin:spatial-vm spacesuit:[fullname of the existing virtual machine] spatial-fabric-array: synchroknot:[name of the new spacesuit] █ Creating a new virtual machine from an existing virtual machine: ■ If a new virtual machine is to be created from an existing virtual machine, then the fullname of that existing virtual machine needs to be given as a spacesuit along with origin:spatial-vm, and the key spatial-fabric-array: needs a value of an IP address where the existing virtual machine is present. The key type: could be blank or can be type:spatial-vm trigger:vm-create type:[blank or spatial-vm] origin:spatial-vm spacesuit:[fullname of the existing virtual machine] spatial-fabric-array: synchroknot:[name of the new virtual machine] █ Creating a Spacesuit from an existing virtual machine: ■ If a Spacesuit is created from an existing virtual machine, then the fullname of that existing virtual machine needs to be given as a Spacesuit along with origin:spatial-vm type:spacesuit, and the key spatial-fabric-array: needs a value of an IP address where the existing virtual machine is present. trigger:vm-create type:spacesuit origin:spatial-vm spacesuit: spatial-fabric-array: synchroknot:
█ Delete
Virtual machine can be deleted using the delete button from the infrastructure engine. You will be prompted for a confirmation while doing so. If the trigger:vm-delete is used from the keyboard, then the fullname of the virtual machine and the IP address of the Spatial Fabric Array where it is located is needed, and the virtual machine will be removed without prompting for confirmation. As a unique feature, the virtual machine can also be deleted if it is in a running or paused state without having to stop it [or processes attached to it or closing all the open consoles], or unconfigure the SpaceBuoy/DHCPCAST/FASTR/Interstellar/Arpless etc or any other Power Module. All the actual complexity associated with virtual machine deletion including its intertwined interdependencies with snapshots and other virtual machines is automatically taken care of by SynchroKnot. Refer to video demonstration
█ Operations
start, stop, pause, unpause, unplug, reset -- these triggers work from the keyboard with the virtual machine's fullname, or with the click of a button. Refer to video demonstration.
█ Spatial Virtual Machine Replica - Writable Snapshot :
A Replica can be created from an existing virtual machine or a spacesuit which may be in a stopped, paused or running state without any interruption or disruption to the existing spacesuit/virtual machine. trigger:create type:replica origin:spatial-vm spacesuit:debian-webserver-1NXddcqaWxTyRLJa8S18kFTMP3Zk3dkMm9 synchroknot:debian-webserver-replica1 *Important : You cannot use the replica if the original virtual machine exists, as it is an identical copy. Fullname of the spacesuit is required. End the virtual machine's replica name with -replica+number Eg. webserver-replica1, webserver-replica8 etc. The virtual machine's replica is identified with a light blue icon. You can create a new virtual machine from a replica [with the replica acting as a spacesuit for the new virtual machine].
█ Time Travel with Spatial Virtual Machine :
Move back and forth in time with specific granularity to the preferred state of the virtual machine at the point in time when the replica was created. First, delete the original virtual machine OR make a replica of the original virtual machine and then delete it. After that, create a virtual machine with its original name from the replica acting as its spacesuit! Multiple simple and complex scenarios are possible.
║█║ Disperser
Note: Disperser was created as experimental feature which is known to work efficiently but the code has not been updated for a while. Refer to video demonstration. trigger:disperser-create spatial-fabric-array:28.9.0.1 synchroknot:192.168.20.25 disperse:10.33.33.33,10.33.33.34 internal-ip:10.33.33.23 trigger:disperser-enable spatial-fabric-array:28.9.0.1 synchroknot:10.33.33.40 trigger:disperser-disable spatial-fabric-array:28.9.0.1 synchroknot:192.168.20.25 trigger:disperser-info spatial-fabric-array:28.9.0.1 synchroknot: trigger:disperser-info spatial-fabric-array:28.9.0.1 synchroknot:192.168.10.25 trigger:disperser-remove spatial-fabric-array:28.9.0.1 synchroknot:28.13.20.25
█ Inter-Weaving
If an IP address of the virtual machine being dispersed to is on a hardware with faster or more cpu cycles, then you could choose to inter-weave that IP address so that it gets more traffic. Eg. disperse:10.33.33.33,10.33.33.34,10.33.33.33,10.33.33.35,10.33.33.33,10.33.33.36,10.33.33.37 ---- here 10.33.33.33 has faster/more cpu cycles. The disperser will not be able to run on specific cpus given to the Tenant [due to its kernel functionality].
║█║ Synchroknot [User]
SynchroKnot is the user identified by his/her Blockchain ID [Bitcoin Address]. Each Synchroknot has a Synchroknot Decentralized Access Control Identification known as SDAC with root and non-root privileges. Synchroknot root user is synchroknot0 [sdac-root] and has all the privileges to control and manage all aspects across all Spatial Fabric Arrays. When a spatial cluster is created on the Spatial Fabric Satellite, the first user with the Blockchain ID [Bitcoin Address] of the spatial cluster is automatically created. The Tenant can log in to the Spatial Fabric Satellite with the spatial cluster's Blockchain ID [Bitcoin Address] the User ID [ i.e same Bitcoin Address] and the Private Key, and then create new users. █ IMPORTANT: ■ Only Bitcoin Address Type Legacy [i.e an address starting with 1] is supported. ■ It is recommended that a Bitcoin Address is generated using the official Bitcoin Core software [available at https://bitcoincore.org]. ■ If using bitcoin-cli or bitcoin-qt [GUI] use the command "getnewaddress" to generate a new Bitcoin Address and the command "dumpprivkey" to get the Private Key associated with your Bitcoin Address. Example: bitcoin-cli getnewaddress "label" legacy bitcoin-cli getnewaddress synchroknot legacy bitcoin-cli getnewaddress "" legacy bitcoin-cli dumpprivkey {Your Bitcoin Address}
║█║ Synchroknot Decentralized Access Control Identification - SDAC and VM-SDAC
Automatic decentralized real-time ad-hoc calibration of credentials of the Synchroknots [SDAC] with those of the virtual machines [VM-SDAC] and vice-versa for fine-grained decentralized access, control and management of the virtual infrastructure. SDAC IDs and VM-SDAC IDs start with the name synchroknot and end with numbers [eg. synchroknot101]. A Synchroknot with SDAC-Root has the privilege to access, manage and control all the virtual machines and the spacesuits of the other Synchroknots. For the non-root Synchroknots to access, manage and control all the virtual machines, their SDAC-ID must pass successful calibration with the VM-SDAC ID of the virtual machine. Each synchroknot and virtual machine can have up to 15 [csv] SDAC and VM-SDAC IDs respectively. For example, if any one of the 15 SDAC IDs of the Synchroknot calibrates successfully with any one of the 15 VM-SDAC IDs of the virtual machine, then that Synchroknot can access, manage and control that virtual machine, and also have the ability to create new virtual machines and replicas from it. Examples: Synchroknot with sdac-id:synchroknot112 will be able to access, manage and control all virtual machines that have vm-sdac-id:synchroknot112 OR vm-sdac-id:synchroknot25,synchroknot112,synchroknot19 and so on. Synchroknot with multiple sdac-ids Eg. sdac-id:synchroknot112,synchroknot25,synchroknot19 will be able to manage and control all virtual machines that have vm-sdac-id:synchroknot112,synchroknot101,synchroknot25,synchroknot19 all together OR separately vm-sdac-id:synchroknot112 | vm-sdac-id:synchroknot25,synchroknot22222 | vm-sdac-id:synchroknot4555,19 OR in any other combination!! *Only SynchroKnot-Root user can modify the SDAC and VM-SDAC IDs.*
█ synchroknot-create
trigger:synchroknot-create spatial-fabric-array:[SFA IP] synchroknot:[Bitcoin ID] trigger:synchroknot-create spatial-fabric-array:28.9.0.1 synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z ***You need to have the sdac-root:synchroknot0 privilege to use the trigger:synchroknot-create. The user created must possess the private key associated with the Bitcoin ID, if not he/she will not be able to log in.*** *value for the key spatial-fabric-array: is needed*
█ synchroknot-info
trigger:synchroknot-info spatial-fabric-array: synchroknot: trigger:synchroknot-info spatial-fabric-array:28.9.0.1 synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z *value for the key spatial-fabric-array: is needed* *Full details will only be viewable by the synchroknot [user] to whom the Spacesuit belongs and to the users who have the sdac-root:synchroknot0 privilege. All other synchroknots [users] will see minimal details.*
█ synchroknot-list
Lists all synchroknots [users] or those that are specifically filtered using microcosm/macrocosm/intercosm. If an IP address of a specific spatial fabric array is given then it lists all the synchroknots on that particular spatial fabric array. Clicking on any one of the results gives detailed information. trigger:synchroknot-list intercosm: macrocosm: microcosm: spatial-fabric-array: d-vector: synchroknot:
█ synchroknot-remove
trigger:synchroknot-remove spatial-fabric-array:28.9.0.1 synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z ***You need to have the sdac-root:synchroknot0 privilege to use the trigger:synchroknot-remove. User with sdac-root:synchroknot0 privilege cannot remove himself, but can remove others as needed.*** *value for the key spatial-fabric-array: is needed*
█ synchroknot-modify
trigger:synchroknot-modify spatial-fabric-array:28.9.0.1 synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z sdac-id:synchroknot19 ▌ You need to have the sdac-root:synchroknot0 privilege to: ■ remove or add the sdac-root:synchroknot0 privilege ■ assign/modify multiple sdac-ids ■ enable/disable status [ie. status:enabled]. * value for the key spatial-fabric-array: is needed. * *** To assign a non-root privilege to a user, *Make Sure* the key sdac-root: has no value given to it. *** *** Those without sdac-root:synchroknot0 privilege *WILL NOT* be able to modify themselves to become sdac-root OR modify their sdac-id. *** ■ The synchroknot-modify trigger below enables user 1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z with sdac-id:synchroknot112,synchroknot25,synchroknot19, while removing synchroknot0 privilege by leaving the value of key sdac-root blank. ■ The trigger below will only be successful if it is initiated by someone with sdac-root:synchroknot0 privilege. trigger:synchroknot-modify spatial-fabric-array:28.9.0.2 synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z sdac-id:synchroknot112,synchroknot25,synchroknot19 sdac-root: status:enabled ■ To disable a synchroknot you must be synchroknot0 : trigger:synchroknot-modify spatial-fabric-array:28.9.0.2 synchroknot:1J3XTYzPeHGPpY7pezBioBSXnahtDLjS7z status:disabled
║█║ Spatial Fabric Array Information, List and Log Panorama
█ spatial-fabric-array-info
trigger:spatial-fabric-array-info spatial-fabric-array:28.9.0.1 synchroknot: *value for the key spatial-fabric-array: is needed* Returns information about the Spatial Fabric Array.
█ Log Panorama:
Click on the displayed IP:Port of Log Panorama in the returned information about the Spatial Fabric Array to open it in a new tab. Use the username and password provided in the information when logging in the first time.
█ spatial-fabric-array-list
trigger:spatial-fabric-array-list Shows a list of Spatial Fabric Arrays along with their information. * It can be used in combination with microcosm, macrocosm and intercosm. *
║█║ Stagnant Virtual Machine
A virtual machine becomes stagnant when its metadata is disabled. The stagnant virtual machine will not show up when using trigger:excerpts or other triggers. The metadata of the virtual machine can be disabled when for example its relocation fails, in which case you are likely to see two virtual machines with the same fullname on two separate Spatial Fabric Arrays. The destination virtual machine, which was waiting for the source to relocate, can be made stagnant as a precautionary measure so that it does not, by some chance, respond to triggers, and then it may be safely deleted. trigger:stagnant-vm spatial-fabric-array: synchroknot: trigger:enable-metadata spatial-fabric-array:[SFA IP] synchroknot:[vm firstname or firstname-lastname] trigger:enable-metadata spatial-fabric-array:28.9.0.1 synchroknot:debian-webserver-1NXddcqaWxTyRLJa8S18kFTMP3Zk3dkMm9 trigger:disable-metadata spatial-fabric-array:28.9.0.1 synchroknot:debian-webserver-1NXddcqaWxTyRLJa8S18kFTMP3Zk3dkMm9
║█║ Zombie Virtual Machine
If a virtual machine has ■█>Z-0-M-B-I-E<█■ shown before the virtual machine when the trigger:stagnant-vm is used then use the trigger below to remove it: trigger:zombie-vm-delete spatial-fabric-array:28.9.0.1 synchroknot:testvm-1NXddcqaWxTyRLJa8S18kFTMP3Zk3dknN1 *value for the key spatial-fabric-array: is needed* ***Make sure you are removing a zombie virtual machine with trigger:zombie-vm-delete and not any other virtual machine.*** SynchroKnot finds zombie virtual machines on deeper inspection of the ZFS volume. In certain cases they may have lingered around after their deletion due to a variety of technical reasons.

║█║ Relocate Virtual Machine

█ Manual Relocation
trigger:vm-relocate data: spatial-fabric-array: destination-spatial-fabric-array: synchroknot: Example: Relocate the virtual machine webserver-32w5Nws7S5SPAd9Uz5oHckuu1eqfPsUC6N from 28.9.0.4 to destination 28.9.0.1 trigger:vm-relocate data: spatial-fabric-array:28.9.0.4 destination-spatial-fabric-array:28.9.0.1 synchroknot:webserver-32w5Nws7S5SPAd9Uz5oHckuu1eqfPsUC6N Note: The IP address where the the virtual machine is located is required [spatial-fabric-array:] along with the IP address of the destination [destination-spatial-fabric-array:].
█ Auto Relocation
Works automatically with the single click of the "AUTO-RELOCATE" button on the Infrastructure Engine. For custom relocation options see below: trigger:vm-relocate d-vector: data: performance: spatial-fabric-array: synchroknot: trigger:vm-relocate intercosm: macrocosm: microcosm: mask: d-vector: data: performance: spatial-fabric-array: synchroknot: Examples: trigger:vm-relocate d-vector: data: performance: spatial-fabric-array:28.9.0.1 synchroknot:webserver-13ttthWjYmTMKtHxx5f7DJ23PpMDri1PHi trigger:vm-relocate intercosm: macrocosm: microcosm: mask: d-vector: data: performance: spatial-fabric-array:28.9.0.1 synchroknot:webserver-13ttthWjYmTMKtHxx5f7DJ23PpMDri1PHi Note: The IP address where the the virtual machine is located is required [spatial-fabric-array:]. ■ To auto select an optimal Spatial Fabric Array at the destination with high performance use key and value : performance:high OR keeping the key performance: blank is the same as high. ■ To auto select an optimal Spatial Fabric Array at the destination with low performance use key and value : performance:low ■ Use the key mask: for a valid network mask [as shown in the Excerpts section]. ■ *** Works with all combinations of Microcosm, Macrocosm and Intercosm for precision auto-relocation. Please read the "Microcosm, Macrocosm, Intercosm" section. *** ■ Make use of distance vector to increase the distance/reach to the destination. ■ To stop the in-progress relocation use the trigger:vm-relocate-stop trigger:vm-relocate-stop spatial-fabric-array: synchroknot: Note: Qemu may not be able to always stop the in-progress virtual machine relocation. *Important: Fullvmname [i.e firstname-lastname] is needed when using the keyboard to trigger:relocate. For fully automatic relocation hit the "AUTO-RELOCATE" button on the Infrastructure Engine. *Important: Only the disks attached to the virtual machines will be relocated with the virtual machine. This unique feature prevents build-up of non-relevant storage which costs the industry exabytes of wasted storage, as not everything is de-duplicated mainly for the reasons of performance and portability. After successful relocation the virtual machine on the source Spatial Fabric Array *WILL NOT* exist [as it will exist on the destination, so don't be surprised to see a message "trigger vm-delete successful" after the "trigger vm-relocate successful" message in realtime log panorama]. █ Option - data:preserve To keep all the storage after successful relocation on the source for whatever reason, use the key and value data:preserve with the trigger:relocate. SynchroKnot automatically makes the source virtual machine stagnant when data:preserve is used. The option data:preserve works with both manual and automatic virtual machine relocation. Example: trigger:vm-relocate data:preserve spatial-fabric-array:28.9.0.4 destination-spatial-fabric-array:28.9.0.1 synchroknot:webserver-32w5Nws7S5SPAd9Uz5oHckuu1eqfPsUC6N trigger:vm-relocate d-vector: data:preserve performance: spatial-fabric-array:28.9.0.1 synchroknot:webserver-13ttthWjYmTMKtHxx5f7DJ23PpMDri1PHi trigger:vm-relocate intercosm: macrocosm: microcosm: d-vector: data:preserve performance: spatial-fabric-array:28.9.0.1 synchroknot:webserver-13ttthWjYmTMKtHxx5f7DJ23PpMDri1PHi *** Important: To prevent failure in virtual machine relocation please make sure the following conditions are adhered to: *** a] Before relocating, the virtual machine's cdrom value must be made blank. If the cdrom is attached, then it must be detached. b] Any open console[s] [java applet, html5, vnc/spice client etc] used to access the virtual machine must be closed. c] The destination *MUST NOT* have a stagnant copy of the virtual machine. d] Please do not perform any operations [pause, unpause etc] while it is relocating. e] Please do not symlink the virtual machine's disk[s] outside the ZFS volume where it was automatically placed at the time of creation. Virtual machines with symlinked disk[s] will not relocate. *** Important: virtual machines with Interstellar and Interstellar Resonance IDs enabled *MUST ONLY* be relocated to Spatial Fabric Arrays that have the Interstellar/ARPless Interstellar Power Module present and active on the Spatial Fabric Satellite. ***

║█║║║ Modify Virtual Machine

█ Legal characters when using trigger:vm-modify: + ; = % , . _ 0-9 a-z A-Z - █ To insert a space use %20 or # Eg. information:This%20is%20SynchroKnot OR information:This#is#SynchroKnot As a built-in security feature aimed at protecting and keeping spatial clusters of Tenants securely bifurcated, certain QEMU options may not work or are not supported. Please refer to the updated QEMU manual for additional details wherever you see [QEMU option(s)]. *** IMPORTANT: Using certain QEMU options requires specific drivers to be present in the virtual machine before you can use those options. It is recommended that those drivers are installed in the virtual machine[s] beforehand, and tested on the QEMU commandline to ensure that they work as expected before you modify the virtual machine Spacesuit. *** █ Multi-order edits are possible with the help of the built-in Intelligent Modification Logic and Engine. You should be able to edit in any order or combination all at once, and all the respective configuration(s) and service(s) will automatically be updated by SynchroKnot! █ Multi-order edits are not possible when used with sub-triggers like Create, Remove, Grow and Shrink virtual disks as explained under the Storage Operations section. █ To unset a value of a key[s] set a blank value to unset it. Eg. key:
█ Virtual Machine Modify Options [trigger:vm-modify] :
■ vm-sdac-id vm-sdac-id:[csv synchroknot[0-9]*] -- and up to 15 comma separated values [csv]. Please keep synchroknot[numbers] sane and not too big. vm-sdac-id:synchroknot100 vm-sdac-id:synchroknot100,synchroknot4000,synchroknot33,Synchroknot2000 ■ Enable Replica replica:enable ■ Disable Replica replica:disable ■ Memory memory:2G ■ CPU cpu:[QEMU option(s)] ■ USB0 USB0 is an automatic USB slot that supports qemu-xhci, ich9-usb-ehci1, pci-ohci. Add usb-tablet or usb-kbd or usb-mouse or all together separated by commas eg. usb-tablet,usb-kbd,usb-mouse Examples: usb0:qemu-xhci,usb-tablet,usb-kbd,usb-mouse -OR- usb0:ich9-usb-ehci1,usb-tablet,usb-kbd,usb-mouse -OR- usb0:pci-ohci,usb-tablet,usb-kbd,usb-mouse ■ USB1 USB1 is an automatic USB slot that supports qemu-xhci, ich9-usb-ehci1, pci-ohci. Add usb-tablet or usb-kbd or usb-mouse or all together separated by commas eg. usb-tablet,usb-kbd,usb-mouse Examples: usb1:qemu-xhci,usb-tablet,usb-kbd,usb-mouse -OR- usb1:ich9-usb-ehci1,usb-tablet,usb-kbd,usb-mouse -OR- usb1:pci-ohci,usb-tablet,usb-kbd,usb-mouse ■ PCI0 PCI0 is an automatic PCI slot that supports i82801b11-bridge|ioh3420|pci-bridge|pci-bridge-seat|pxb|pxb-pcie|x3130-upstream|xio3130-downstream. Examples: pci0:ioh3420 pci0:i82801b11-bridge pci0:ioh3420,[option[s] separated with comma[s]] ■ VIRTIO0 VIRTIO0 is an automatic VIRTIO slot that supports virtio-keyboard|virtio-mouse|virtio-tablet|virtio-gpu Add virtio-keyboard or virtio-mouse or virtio-tablet or virtio-gpu with options separated with commas or all together separated by commas eg. virtio-keyboard,virtio-mouse,virtio-tablet,virtio-gpu Examples: virtio0:virtio-keyboard,virtio-mouse,virtio-tablet,virtio-gpu virtio0:virtio-gpu,{option[s] separated with comma[s]} virtio0:virtio-tablet virtio0:virtio-keyboard virtio0:virtio-mouse ■ VIRTIO1 VIRTIO1 is an automatic VIRTIO slot that supports virtio-keyboard|virtio-mouse|virtio-tablet|virtio-gpu Add virtio-keyboard or virtio-mouse or virtio-tablet or virtio-gpu with options separated with commas or all together separated by commas eg. virtio-keyboard,virtio-mouse,virtio-tablet,virtio-gpu Examples: virtio1:virtio-keyboard,virtio-mouse,virtio-tablet,virtio-gpu virtio1:virtio-gpu,{option[s] separated with comma[s]} virtio1:virtio-tablet ■ VIRTIO2 VIRTIO2 is an automatic VIRTIO slot that supports virtio-keyboard|virtio-mouse|virtio-tablet|virtio-gpu Add virtio-keyboard or virtio-mouse or virtio-tablet or virtio-gpu with options separated with commas or all together separated by commas eg. virtio-keyboard,virtio-mouse,virtio-tablet,virtio-gpu Examples: virtio2:virtio-keyboard,virtio-mouse,virtio-tablet,virtio-gpu virtio2:virtio-gpu,{option[s] separated with comma[s]} ■ VIRTIO3 VIRTIO3 is an automatic VIRTIO slot that supports virtio-keyboard|virtio-mouse|virtio-tablet|virtio-gpu Add virtio-keyboard or virtio-mouse or virtio-tablet or virtio-gpu with options separated with commas or all together separated by commas eg. virtio-keyboard,virtio-mouse,virtio-tablet,virtio-gpu Examples: virtio3:virtio-keyboard,virtio-mouse,virtio-tablet,virtio-gpu virtio3:virtio-gpu,{option[s] separated with comma[s]} ■ BIOS Set the filename for the BIOS. The file must be present in the storage volume of the virtual machine. bios:[filename] ■ RTC Set the realtime clock rtc:[QEMU option(s)] ■ Watchdog The following hardware watchdog models are supported: ib700|i6300esb|diag288 The following watchdog actions are supported: pause|shutdown|poweroff|debug|none|reset. If the key watchdog-action: is not set it will default to the watchdog action reset. Please refer to the QEMU manual for more details. Example: watchdog:[ib700|i6300esb|diag288] watchdog-action:pause watchdog:ib700 ■ Virtualization By default, virtualization is set to KVM. For pure emulation, set the value to qemu. virtualization:qemu ■ Keyboard keyboard:[QEMU option(s)] ■ SMP smp:[QEMU option(s)] ■ Location eg. location:boston location:Washington%20DC location:Washington#DC Legal characters: % - _ 0-9 a-z A-Z ■ Excerpts Up to 15 comma separated values. Legal characters: 0-9 a-z , - eg. excerpts:linux,webserver,production ■ Spice Console Password spice-password:[less than 15 characters.] ■ VNC Console Password vnc-password:[less than 25 characters.] ■ Boot Order boot:[cdrom0 | cdrom1 | disk0 - disk24] The virtual machine can boot from either cdrom0 or cdrom1 or any one of the disks from 0 to 24 i.e disk0 to disk24. ■ CDROM The iso must already be present in the virtual machine's storage volume to be attached. cdrom0:[name of the iso] -- will attach the cdrom when the virtual machine is started from the stopped state. cdrom1:[name of the iso] -- will attach the cdrom when the virtual machine is started from the stopped state. cdrom0-attach:[name of the iso] -- will attach the cdrom to a running virtual machine. The cdrom0:[name of the iso] must be set before that. cdrom1-attach:[name of the iso] -- will attach the cdrom to a running virtual machine. The cdrom1:[name of the iso] must be set before that. cdrom0-detach: -- detaches the attached cdrom from a running virtual machine. cdrom1-detach: -- detaches the attached cdrom1 from a running virtual machine. *** Important: Before relocating, the virtual machine's cdrom0/cdrom1 value must be made blank by modifying the key without assigning it a value [eg. cdrom0: and cdrom1: ]. If the cdrom is attached then it must be detached. *** ■ Machine machine:[QEMU option(s)] ■ Soundhw soundhw:[QEMU option(s)] ■ VGA vga:[QEMU option(s) eg. std|cirrus|none] ■ Remove Migration Tag In some failed virtual machine relocations the virtual machine might show that it is still migrating, but it might not have migrated due to an underlying failure. So, to remove this tag do: migration-tag:remove

║█║║║ Network Operations

■ Add NIC add-nic:[single or csv from 0 to 49] Eg. add-nic:1 OR add-nic:1,2,3,4,5,6,7,8,9 Note: change the NIC status to plugged after adding it for it to show up in the virtual machine. Read more about NIC Status below. ■ Delete NIC Eg. delete-nic:1 OR delete-nic:1,2,3,4,5,6,7,8,9 ■ NIC Status - Plugged and Unplugged Once the NIC has been added with add-nic it will not be plugged into the virtual machine unless one plugs it in. The results of plugging and unplugging NIC(s) take effect at the starting of the virtual machine from the stopped state. Operating systems may benefit from recognizing the NIC that was plugged back after being previously unplugged, and might keep the same ordering, name and other details, reducing the chances of misconfiguration. nic1-status:plugged nic1-status:unplugged add-nic:1 nic1-status:plugged It is also possbile to add an NIC, plug it in and assign it an IP address, Netmask and all the SpaceBuoy options [see below] all together in one shot! add-nic:1 nic1-status:plugged nic1-ip:10.33.33.33 nic1-gateway-ip:10.33.33.1 ■ NIC Model nic[0-49]-model:[QEMU option(s)] Eg. nic0-model:e1000 ■ NIC MAC Address nic[0-49]-mac:[Last 5 hexadecimal characters of a mac address] Eg. nic0-mac:12345 Note: a unique algorithmically-generated MAC address specific to virtual machine and its network interface is assigned when a new virtual machine is created or when a new NIC is added. To change that use nic[0-49]-mac: and/or nic[0-49]-interstellar-mac: ■ NIC Interstellar MAC Address nic[0-49]-interstellar-mac:[First 7 hexadecimal characters of the MAC address with dac as a prefix] Eg. nic0-interstellar-mac:dac0001 ■ NIC Interstellar Resonance - This works only with the Interstellar/Arpless Interstellar Power Module nic[0-49]-interstellar-resonance:[First 7 hexadecimal characters of the MAC address with dac as a prefix and up to 10 Interstellar Resonance IDs csv] nic0-interstellar-resonance:dac0002 nic0-interstellar-resonance:dac0002,dac0004 *** Interstellar Resonance IDs can be anything other than nic[0-49]-interstellar-mac. *** ■ INTERSTELLAR OUI - This works only with the Interstellar/Arpless Interstellar Power Module interstellar-oui:[6 hexadecimal characters of the MAC address of the target physical hardware or virtual machine which could be a switch, router, dhcp server etc. Up to 10 OUI IDs csv]
║█║ SpaceBuoy
■ NIC IP Address - add public or private IP address to NIC using SpaceBuoy automatically. nic0-ip:[ip address in the 10|172|192 range] -- Eg. nic[0-49]-ip Eg : trigger:modify synchroknot:debian-webserver-1NXddcqaWxTyRLJa8S18kFTMP3Zk3dkMm9 nic0-ip:10.33.33.33 nic0-gateway-ip:10.33.33.1 Note: Assigning a public IP address may work for you. Assigning public IP addresses starting with 101 to 110 are known to not work [i.e the virtual machine does not receive these IP addresses]. There may be other public addresses that may not work, but for the most part it seems to be working fine. Please take a look at one of the demo videos to get a better understanding. █ Important: ■ To reinstate all the additional options below into the SpaceBuoy, it is required to add or re-add the NIC IP Address [eg. nic[0-49]-ip:] ■ The operating system DHCP client must support the standard DHCP features. Below are the modifications: ■ NIC IP Gateway Address - add public or private IP gateway address using SpaceBuoy automatically. nic0-gateway-ip:[gateway ip address in the 10|172|192 range] -- Eg. add-nic[0-49]-gateway-ip ■ NIC Netmask - add netmask for the NIC IP Address. nic0-netmask:[valid legal netmask] -- Eg. nic0-netmask:255.255.255.0 ■ NIC Broadcast - add broadcast for the NIC IP Address. nic0-broadcast:[valid legal broadcast] -- Eg. 192.168.1.255 ■ NIC DNS Server -- add up to five DNS Server IP addresses separated by a comma nic0-dns-server: ■ NIC Domain Name - add a domain name nic0-domain-name:[domain name] -- Eg. nic0-domain-name:synchroknot.everywhere ■ NIC Domain Search nic0-domain-search:[domain name] ■ NIC NTP Server nic0-ntp-server: ■ NIC MTU - add a MTU nic0-mtu:[legal MTU size] ■ NIC Classless Static Route - Set a classless static route for the network interface. nic0-classless-static-route: ■ NIC IP Forward Enable - Enable IP forwarding for the interface. nic0-ip-forward-enable: ■ NIC Log Server nic0-log-server: ■ NIC Netbios NS nic0-netbios-ns: ■ NIC Netbios DD nic0-netbios-dd: ■ NIC Netbios Node nic0-netbios-nodetype: ■ NIC SMTP Server nic0-smtp-server: ■ NIC Pop3 Server nic0-pop3-server: ■ NIC TCP Keepalive nic0-tcp-keepalive:
║█║ DHCPCAST
■ To enable DHCPCAST for a network interface: nic[0-49]-dhcpcast:[mac address of the destination dhcp server without the : separator] Eg. trigger:vm-modify synchroknot:debian-webserver-1NXddcqaWxTyRLJa8S18kFTMP3Zk3dkMm9 nic0-dhcpcast:dac000143797 ■ To disable dhcpcast, simply set a blank nic[0-49]-dhcpcast: OR nic[0-49]-ip: Eg. trigger:vm-modify synchroknot:debian-webserver-1NXddcqaWxTyRLJa8S18kFTMP3Zk3dkMm9 nic0-dhcpcast: * Important: If you use the Interstellar Power Module, the destination dhcp server should have the same Interstellar ID or Interstellar Resonance ID. In the case where you happen to use the Interstellar Power Module and the dhcp server cannot have the same Interstellar ID or Interstellar Resonance ID, then one can set the interstellar-oui. *
║█║ Flood Control
Flood Control is a built-in mechanism for protection from various types of flooding within and across the Spatial Cluster. It is designed to reduce the number of specific types of packets exiting the virtual machine. It can be enabled on a virtual machine. If enabled on a Spacesuit, then all the virtual machines created from that Spacesuit will inherit the Flood Control properties. Flood Control works with ARP, Multicast, DHCP4 [IPv4], DHCP6 [IPv6], DNS and IPv6 related Router Solicitation, Router Advertisement, Neighbour Solicitation and Neighbour Advertisement. No agent / software needs to be installed in the virtual machine. Flood Control automatically takes care of all the complexities when used along with SpaceBuoy, DHCPCAST, ARPLESS Interstellar, Interstellar and other Built-ins and Power Modules. Flood Control can be modified with the trigger vm-modify. The options below can be modified as a single modification or multiple modifications [i.e all in a line along with modifications other than those of Flood Control!] as preferred. All the underlying complexities will be taken care of by Synchroknot by allowing all the modifications to be performed automatically and the results reflected in realtime. There are two components: 1] Limit - maximum average packets to limit/reduce per second, minute, hour or day. packets/[second|minute|hour|day] - Eg: 2/minute 2] Burst - maximum initial packets allowed until Limit takes effect. Value for the key *-burst is not a requirement. *IMPORTANT*: ■ Only Synchroknot root user [synchroknot0] can make these modifications. ■ Setting a very low Limit and/or Burst may adversely affect the virtual machine communication. ■ Setting a high Limit and/or Burst may not reduce the excessive traffic. ■ Determine the appropriate Limit and/or Burst for the virtual machine by testing the functionality end-to-end. Eg. If DHCP4 Limit/Burst is set, then see if the virtual machine gets an IP address from SpaceBuoy, DHCPCAST or DHCP server. If ARP Limit/Burst is set then test if the virtual machine can ping other virtual machines present in the Spatial Cluster [i.e able to send and receive ARP packets] and so on. The following options are supported: ■ ARP arp-limit: arp-limit-burst: Eg: arp-limit:6/minute arp-limit-burst:18 ■ DHCP4 dhcp4-limit: dhcp4-limit-burst: Eg: dhcp4-limit:6/minute dhcp4-limit-burst:18 ■ DHCP6 dhcp6-limit: dhcp6-limit-burst: ■ DNS dns-limit: dns-limit-burst: ■ Multicast multicast-limit: multicast-limit-burst: ■ IPv6 Router Solicitation router-solicitation-limit: router-solicitation-limit-burst: ■ IPv6 Router Advertisement router-advertisement-limit: router-advertisement-limit-burst: ■ IPv6 Neighbour Solicitation neighbour-solicitation-limit: neighbour-solicitation-limit-burst: ■ IPv6 Neighbour Advertisement neighbour-advertisement-limit: neighbour-advertisement-limit-burst:

║█║║║ Storage Operations

■ Disk Attach Slot disk[0-24]-attach-slot:[name of the virtual disk. This virtual disk must be present in the virtual machine's storage volume. The attached disk will be seen by the operating system when it is started from a stopped state. It would be logical to keep the disk name as same as the disk[0-24]-attach-slot name if possible.] Eg. disk1-attach-slot:disk1 █ IMPORTANT: *** When a disk is attached it is automatically given the QEMU option of type as virtio-blk-pci, format as raw and cache as writeback. These options can be changed. The raw format [with type virtio] is known for its performance and works well on ZFS. QEMU is known to not start after removing the writeback option on ZFS. It is recommended that these options are not tweaked. *** *** Please make sure the necessary virtio drivers are pre-installed in the operating system running in the virtual machine if you would like it to boot or use the virtual disks with the type virtio-blk-pci. *** Below are the options to modify the type and cache: ■ Disk Type disk[0-24]-type:[virtio-blk-pci|virtio-scsi-pci|nvme|ide-drive] Eg. disk0-type:virtio-blk-pci ■ Disk Cache disk[0-24]-cache:[writeback refer QEMU option(s)] Eg. disk1-cache:writeback ■ Disk Format disk0-format:[raw or qcow2 refer QEMU option(s)] ---- disk[0-24]-format -- up to 25 virtual disks supported. Eg. disk0-format:raw ■ Disk Detach Slot disk[0-24]-detach:[name of the virtual disk. This virtual disk must be present in the virtual machine's storage volume. The detached disk will not be seen by the operating system when it is started from a stopped state.] Eg. disk1-detach-slot:disk1
■ Create Virtual Disk
To trigger:vm-modify add the following options to create a disk: disk:create name:[name of the disk] type:[raw|qcow2] size:[eg. 50K or 50M or 50G or 50T - capital K/M/G/T is required for kilobytes, megabytes, gigabytes and terabytes] Example: trigger:vm-modify spatial-fabric-array:[ip address] synchroknot:[virtual machine name] disk:create name:[diskname.raw] type:raw size:50M trigger:vm-modify spatial-fabric-array:[ip address] synchroknot:[virtual machine name] disk:create name:[diskname.qcow2] type:qcow2 size:50M *** IMPORTANT : trigger:vm-modify cannot have any other edits when used with sub-trigger disk:create. ***
■ Create Virtual Disk with a specific Block Size
Create a virtual disk with a specific block size to match the block size requirements of the applications [eg. databases etc] in the virtual machine. * Only works for the disk format qcow2. * To trigger:vm-modify add the following options to create a qcow2 disk with a specific block size: disk:create name:[diskname.qcow2] block-size:8K type:qcow2 size:50M *** block-size must be a power of two between 512 and 2048K [i.e 512 and 2048K/2M] *** Example: trigger:vm-modify spatial-fabric-array:[ip address] synchroknot:[virtual machine fullname] disk:create name:diskname.qcow2 block-size:8K type:qcow2 size:50M The virtual disks should be created quickly and will be shown under the storage volume of the virtual machine. In some cases, when a large virtual disk is created and the system resources are engaged in other tasks, the progress of the disk creation can be seen under the Storage Volume by comparing the "virtual size" to "disk size" of the disk being created [and clicking on information to refresh the data].
■ Remove Virtual Disk
To trigger:vm-modify add the following options to remove a disk: disk:remove name:[diskname.qcow2] *** Caution: the virtual disk will be permanantly removed. *** *** IMPORTANT : trigger:vm-modify cannot have multiple edits when used with sub-trigger disk:remove. *** Example: trigger:vm-modify spatial-fabric-array:[ip address] synchroknot:[virtual machine name] disk:remove name:[diskname.qcow2]
■ Grow Virtual Disk
To trigger:vm-modify add the following options to grow a disk: disk:grow name:[diskname.raw] type:raw size:50M *** IMPORTANT : trigger:vm-modify cannot have multiple edits when used with sub-trigger disk:grow. *** Example: trigger:vm-modify spatial-fabric-array:[ip address] synchroknot:[virtual machine name] disk:grow name:[diskname.raw] type:raw size:50M trigger:vm-modify spatial-fabric-array:[ip address] synchroknot:[virtual machine name] disk:grow name:[diskname.qcow2] type:qcow2 size:100M
■ Shrink Virtual Disk
To trigger:vm-modify add the following options to shrink a disk: disk:shrink name:[diskname.raw] type:raw size:50M *** IMPORTANT : trigger:vm-modify cannot have multiple edits when used with sub-trigger disk:shrink. *** *** Caution: Before attempting to shrink a virtual disk, you *MUST* use file system and partitioning tools inside the virtual machine to reduce the allocated file system[s] and partition size[s]. Failure to do so will result in data loss *** * Caution: QCOW2 does not seem to support shrinking the virtual disk images. * Example: trigger:vm-modify spatial-fabric-array:[ip address] synchroknot:[virtual machine name] disk:shrink name:[diskname.raw] type:raw size:50M
║█║ Storage Datapath Access
Storage Datapath Access allows you to push and pull data [virtual machine disks, ISOs, spacesuits] to and from any Spatial Fabric Array. This can also be used as a pull-based back-up and/or archiving system. Another great use of Storage Datapath Access is the ease with which one can perform secure, controlled updating and versioning of spacesuits. For example, you can keep the main/original copy of the virtual machine spacesuit(s) at your location [head office, lab, control center, etc.], update the image with security, package and operating system updates/upgrades, test the functionality end-to-end, and then push it [only changed blocks] to as many Spatial Fabric Arrays that have those spacesuit(s)!! █ To access data, simply use : trigger:spatial-fabric-array-info spatial-fabric-array:[IP address] and look for port next to Storage Data Path OR trigger:spatial-fabric-array-list and look for S-PATH:[number] which is the port number of the Spatial Fabric Satellite then do: rsync -a rsync://sknt0@10.9.0.1:22837 --password-file=[path to the file in the Linux user's home directory that contains the password. For ease of use, the file name can correspond to the rsync username sknt0|sknt1|sknt2.] Example: rsync -a rsync://sknt0@10.9.0.1:22837 --password-file=/root/sknt0 *** Important: Make sure the password file is in the Linux user's home directory and only that Linux user has the reading rights to it, eg. chmod 400 root:root /root/[your-password-file] *** Example output: spatial-fabric-array-log SYNCHROKNOT SPATIAL FABRIC ARRAY LOG ACCESS: Logs for 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE @ 28.9.0.1 tier0-spacesuit SYNCHROKNOT TIER0 STORAGE DATAPATH ACCESS: virtual machine spacesuit for 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE @ 28.9.0.1 tier0-spatial-vm SYNCHROKNOT TIER0 STORAGE DATAPATH ACCESS: virtual machines for 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE @ 28.9.0.1 tier0-resource-volume SYNCHROKNOT TIER0 STORAGE DATAPATH ACCESS: resource volume for 1PeDaGo6Uj9HWdVQs8zJAYeQ1478xrpwLE @ 28.9.0.1 Note: You can then access all the volumes displayed and push/pull data. █ To set/modify the password of datapath secrets use the trigger:datapath-secrets-modify. ■ Up to four users [with usernames sknt0, sknt1, sknt2, sknt3] are allowed for multiple access to Storage Datapath. ■ Only Synchroknot root user [synchroknot0] can modify the passwords of sknt0, sknt1, sknt2 and sknt3. Eg. trigger:datapath-secrets-modify sknt0:yourpassword Eg. trigger:datapath-secrets-modify sknt0:yourpassword sknt1:sknt1password sknt2:sknt2password sknt3:sknt3password █ To get the datapath secrets usernames and passwords use the trigger: trigger:datapath-secrets-info ■ Only Synchroknot root user [synchroknot0] can view the usernames and passwords.
║█║║║ Spatial Fabric Satellite : Deployment Options
Cubicles, offices, shops, apartments, basements, wireless base stations, fibre optic hubs/stations etc. instead/alongside centralized data centers. Keep Spatial Fabric Satellites with virtual machines that communicate with each other with frequent/high network I/O in proximity to each other [Eg. within the same location i.e shelf/rack or close enough location[s]]. The network speed, capacity and bandwidth requirements mainly depend on the type of applications running in the virtual machines and the rate at which the infrastructure is scaled horizontally and/or vertically.

║█║║║ Built-in Automatic Switch with SATELLITE TREE PROTOCOL :

Satellite Tree Protocol is now available for free on the SynchroKnot Official Website along with an article on how to learn and use it! SynchroKnot software comes built-in with an *ACTUAL* automatic switch with Satellite Tree Protocol. It allows Spatial Fabric Satellites [i.e any commodity X86_64 hardware] to be directly connected to eachother utilizing proven network topologies and without having to configure anything! SynchroKnot software enables and transforms commodity hardware into an *ACTUAL* switch [eg. as seen in products from Cisco, Juniper and others], and not virtual switches like Open Virtual Switch [OVS] and related software. With this unique built-in automatic functionality, if you prefer, you *DO NOT* need physical or virtual switches anymore. Don't forget to see and learn from the demonstration videos and the explanations under the demo section of the website. To disable it for whatever reason, simply turn off STP with the brctl utility on all Spatial Fabric Satellites that see eachother on layer 2 : brctl stp synchroknot0 off Note: after disabling Satellite Tree Protocol you can use standard Ethernet switches and enable STP/RSTP, etc. on them as needed to connect Spatial Fabric Satellites. Channel Bonding is not supported on Spatial Fabric Satellites. The source code of the bridge kernel module should as usual be available at kernel.org or other locations. Feel free to not use it for whatever reason that deems fit. █ If you would like to use and benefit from the built-in Satellite Tree Protocol then: ■ Make sure your Ethernet ports [NIC/USB] are functional. ■ *** Important : *MAKE SURE* the Spanning Tree Protocol / Rapid Spanning Tree Protocol *DO NOT* reach Spatial Fabric Satellites. *** *** You should not need more than 4 Ethernet ports per Spatial Fabric Satellite unless you intend to use custom topologies. Only 2 Ethernet ports are needed for Ring topology and 4 Ethernet ports for Torus topology. *** Apart from Ethernet ports utilized in the direct connection of Spatial Fabric Satellites, an extra Ethernet port will be needed on those Spatial Fabric Satellite[s] that will be used to connect to your gateway[s] *** ■ To reduce uncertainties in the network, please do not connect Gigabit Ethernet port[s] to a 10 Gigabit Ethernet port[s]. ■ Choose the topology that suits your requirement below. An advanced topology guide may be available upon request!
2 Port NIC for 1-D Ring Topology [X Axis] and 4 port NIC for 2-D Torus Topology [X and Y Axis].








Seamless Incremental Network Expansion of 1-D Ring Topology [using both one long cable and single length cable].








2-D Torus Topology.







Seamless Incremental Network Expansion of X and Y Axis.







Multipath Optimized Routes and Links for Mission Critical Operation.




║█║║║ SynchroKnot Auto NAT Enablement

SynchroKnot Auto NAT Enablement allows for transparent access to Infrastructure Engine and Virtual Machine Consoles [HTML5/Java], Log Panorama and more from behind NAT [Network Address Translation]. This feature allows for secure and easy setup & access from behind standard NATs so that Tenants can have direct access, or access from their VPNs without accessing the actual provider network. This feature brings about flexibility and simplicity, while at the same time allows the service providers to securely keep the Tenants separated. Excerpt from the SynchroKnot Manual: The Infrastructure Engine can be accessed by all Tenants in the 10.xxx.xxx.xxx range corresponding to the 28.xxx.xxx.xxx range IP address given to the Spatial Fabric Satellite. Eg. https://10.9.0.1/SynchroKnot.sknt To access the SynchroKnot Infrastructure Engine on a Spatial Fabric Satellite from the above description, the IP address of the machine used to access the Infrastructure Engine from the web browser must be in the 10.x.x.x range for security reasons. If you have a Tenant behind a transparent NAT in the 172.x.x.x range for example, and it is pointed to the 10.x.x.x range to access the Infrastructure Engine, then the access is possible but with certain limitations. The Infrastructure Engine will not know about the 172.x.x.x range from where the request is coming in, as it is on the other side of NAT. Therefore, the response[s] given would still be pointing to the 10.x.x.x range. This would cause the http and other requests & redirects such as Cross Domain Ajax, the opening of new tabs for websocket based HTML5 console access, Java based console access, Log Panorama .... and much more to NOT work. Example scenarios without the use of SynchroKnot Auto NAT Enablement: ■ Scenario A Works: [ web browser in 10.x.x.x range ] ------------> [ Infrastructure Engine in 10.x.x.x range ] Different types of redirects sent from the Infrastructure Engine work transparently. ■ Scenario B Does Not Work: [ web browser in 172.x.x.x range ] -----> [ NAT ] ------> [ Infrastructure Engine in 10.x.x.x range ] [ web browser in 192.x.x.x range ] -----> [ NAT ] ------> [ NAT ] -----> [ Infrastructure Engine in 10.x.x.x range ] Different types of redirects sent from the Infrastructure Engine are pointing in the 10.x.x.x. The web browsers in 172 & 192 ranges behind single and double NATs will trigger the redirect in the 10.x.x.x range but will not be able reach the destination in the 10.x.x.x range. The SynchroKnot Auto NAT Enablement feature transparently addresses this issue and allows full access just as if you were accessing the Infrastructure Engine from the 10.x.x.x network. The above Scenario A and B would work with SynchroKnot Auto NAT Enablement. This should work with any transparent NAT [eg. with IPtables etc]. This unique solution was possible with the combination of partly server-side + partly server-side-embedded-client-side functionality [which is unique to SynchroKnot]. One does not have to touch the transparent firewall! Eg. If you were using IPtables to DNAT and SNAT/Masquerade on a transparent NAT box in between, then simply set the 172.x.x.x range to point to 10.x.x.x. range. That's it. No need for further reconfiguration, updating the rules for mapping/unmapping/remapping ports, IP addresses etc. [We will share the details of how to set up a transparent IPtables NAT in our manual shortly.]

Creative Commons License
SynchroKnot [ website - content - technology - architecture - methodology ] by SynchroKnot is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.
Based on a work by its creator Mehul Sharma at SynchroKnot : synchroknot.[world|de|ch|tokyo|com|org|in|ru].