Planned maintenance work 2021-06-20

When: Sunday 12.00 – 18.00 on 2021-06-20
Why: Datacenter facility provider maintenance
Affects: Hammarby Datacenter, Interconnect between Hammarby DC and other datacenters
as well as other services on 46.253.192.0/20 hosting range

Details:
Our datacenter provider GlobalConnect are performing structural integrity improvements in the facility. This requires us to move equipment in the zone we’re located in. We’ll be doing this with ”construction electricity” to avoid powering down the equipment.

We need to move some uplink cables, which may cause momentary interruptions.
Our intention is that the disruptions will only last minutes at a time, but we’re still announcing a service window. Please plan your activities and services according this this service window.

Network issue 2021-05-09

We had an issue with a core switch for our bladechassis that did not failover as it should following a fault.
Switch was still reporting functional and secondary switches did not take over as they should. This caused delay in troubleshooting process.

Effected datacenters: VBDC , interconnection between VBDC and HY
When: 12.55 CET – 13.41 CET
Component: dr-se-vb-sw02

We’ll perform software updates during night time to prevent any software causes if this issue.
If it still happens again, we’ll replace the switch as faulty.

Maintenance window / router maintenance

Adminor is scheduling a router maintenance effecting customers on IPranges: 46.253.192.0/20 and 185.111.240.0/22 .

Primary Service window is 2021-03-22 Monday 00.00 – 04.00 (two week notice!).

We are aiming for an outage less than 30min (15min or less usually), but keeping the window longer incase we hit an unforeseen snag or hardware issues that needs to be resolved.

Emergency service window (if we need to schedule sooner) 2021-03-15 Monday 00.00 – 04.00 CET.

We will try to keep this maintenance brief but are letting you know as our valued customer.
 
Best regards
Adminor AB

Azure and Azure files MMAP broken

We found out (or rather re-discovered) that Azure Files CIFS implementation does not correctly support mmap function that is used in some softwares.

It has been previously reported on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900821 but we thought it might be worth clarifying this for people spending a lot of time googling why their apache2 fails to deliver files larger than 1MB.

The default setting in apache2 does not mmap files smaller than 1MB hence why the issue is not noticed on small files or files not hosted on the CIFS volume. Large files from the affected volume will however cause a ”Read error at byte X/ X (Bad address). Retrying.” error if you try to wget or download the files via apache2 on a web app using Azure Files mounted CIFS storage (path mapping).

Some searches might lead you to investigate apache2 file limitations preventing files larger than 1MB from beint transmitted.
LimitRequestBody is not a fix for this issue.

Scenario:
Azure web app or VM with Apache2 or other mmap using software fails to read files properly from Azure Files mounted ”path mapping” volumes which uses CIFS.

Workaround:
EnableMMAP off

This configuration line can be done per affected Directory, global apache2 config or in the vhost.

Network dip

One of our upstream transits suffered an outage at 19.05. This caused network re-routing to happen and may have been felt as momentary network dip.
Traffic has been re-routed to failovers. We’re monitoring the networks.

When: 19:05 – 19:10 (upstream has failed over)
Impact: 5min re-routing, traffic dip
What: 46.253.192.0/20

Update: Some more network dips occured during the evening. The network upstream suspected of causing high CPU usage in our cores have been isolated. We’re continuing to monitor the situation.

When: 20.30, 23.30 , duration (roughly 2-3min per incident)